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Preface 



This guide describes tools to troubleshoot IEEE 802.3 LAN link hardware con- 
necting HP 3000 MPE-V systems. 

The primary tool described is LANDIAG, the HP 3000 Local Area Network (LAN) 
Diagnostic software utility. If you have a hardware problem on your HP 3000 
LAN link, you can use LANDIAG along with the other tools to locate the Field 
Replaceable Unit (FRU) at fault. You must then repair or replace the faulty 
FRU. 

This guide supplements other LAN troubleshooting manuals, as follows: 

1. The LAN Link Hardware Troubleshooting Manual, IEEE 802.3 Coaxial 
Cable LAN, 5955-7681, covers the troubleshooting of HP ThinLANs and 
ThickLANs (thin and thick coaxial cable LANs) comprised of dissimilar sys- 
tems (such as HP 1000 RTE-A, HP 9000 Series 300, 500 and 800 HP-UX, and 
HP 3000 MPE-V systems). It uses a portion of the LANDIAG software in- 
formation contained here. (The HP CE Handbook version of this manual is 
5959-2217.) 

2. The HP ThinLAN Diagnostics and Troubleshooting Manual for PCs, 
50909-90060, is directed toward HP personal computer ThinLAN networks. 
When HP 3000 systems are connected, the LANDIAG information presented 
here is essential. 

3. The troubleshooting process for HP StarLAN, featuring twisted-pair cables, 
is covered by the HP Star LA N Diagnostics and Troubleshooting Manual for 
PCs, 50906-90060. When HP 3000 MPE-V systems are connected to 
StarLAN, the LANDIAG information presented here is also needed. 

4. If the problem lies in LAN software, rather then the hardware, the 
NS3000/V Network Manager Reference Manual (32344-90002) should be 
consulted. 

The intended audiences for this guide include the Network Manager, the 
Network Consultant, the Data Comm Specialist, and the Hewlett-Packard 
Customer Engineer (CE) and Systems Engineer (SE). 
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How To Use This Guide 



All users should read Chapter 1 to become acquainted with general troubleshoot- 
ing considerations and tools covered by this guide. As a reference manual, users 
can subsequently proceed to the chapter describing the particular tool of interest. 

For those users who lack troubleshooting procedures, Appendix A is provided. 
Appendix A provides procedures, as a series of decision-tree flowcharts, to help 
isolate HP 3000 LAN link hardware faults. These procedures utilize LANDIAG 
and other tools presented in the various chapters. 



Organization Of This Guide 



This guide consists of the following chapters: 

Chapter 1: General Information 

Chapter 2: SHOWCOM 

Chapter 3: Activity LEDs 

Chapter 4: LAN Node Diagnostic 

Chapter 5: LANIC Self Test 

Chapter 6: Tracing 

Chapter 7: Software Tools 

Appendix A: Troubleshooting Flowcharts 
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Additional References 



When using this manual, you should be familiar with the basic operating prin- 
ciples of HP 3000 computers and the MPE-Y operating system. In addition, you 
should be familiar with the subjects covered in the following manuals, as 
appropriate: 



• HP 3000 Computer Systems, MPE V Commands Reference Manual 
(32033-90006) 

• HP 3000 Computer Systems, MPE V Intrinsics Reference Manual 
(32033-90007). 

• HP 3000 Computer Systems, MPE V System Operation and Resource 
Management Reference Manual (32033-90005) 

• Fundamental Data Communications Handbook (5979-4634) 

• LAN Cable and Accessories Installation Manual (5955-7680), for coaxial 
cable LANs 

• HP 3000 LAN Link installation and service manuals, including 

- HP 30240A LAN3000/V Link LANIC Installation and Service Manual 

(part number depends on the product option selected) 

- HP 30265A StarLAN/3000 Link Installation and Service Manual 

(30265-90001), for Series 37 and MICRO 3000 systems 

• NS3000/V Network Manager Reference Manual (Volume 1, 32344-90002; 
Volume 2, 32344-90012) 

• NS3000/V User/Programmer Reference Manual (32344-90001) 

• NS3000/V Error Message and Recovery Manual (32344-90005) 

• HP StarLAN Planning Guide for PCs (50906-90020) 

• HP Site Wire Planning Guide (5959-2201) 
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Conventions Used 



NOTATION 

UPPERCASE 
Boldface 



italics 



lowercase 
nonbold 

[ ] 



( > 



DESCRIPTION 

Words in uppercase or boldface text must be entered exactly as shown. 
Punctuation characters other than brackets, braces and ellipses must also be entered 
exactly as shown. For example: 

EXIT; 

Words in syntax statements that are in italics denote a parameter that must be 
replaced by a user-supplied variable. For example: 

CLOSE filename 

Words in lowercase or nonbold text denote substitutable variables or user-defined 
strings. 

An element inside brackets in a syntax statement is optional. Several elements 
stacked inside brackets means the user may select any one or none of these ele- 
ments. For example: 



User may select A, B or neither. 



When brackets are nested, parameters within inner brackets can be specified only if 
parameters in the outer brackets or commas (place holders) are specified. For 
example: 

[ pa rm 1 [ , pa rm2 [ , pa rm3 ] ] ] can be entered as: 

parm1 ,parm2,parm3 or parmi , ,parm3 etc. 

Optional parameters that are not position-related are as follows: 

[parm1] [,parm2] 

When several elements are stacked within braces in a syntax statement, the user 
must select one of those elements. For example: 



<: B > User must select A or B or C. 

Icj 

Vertical parallel lines indicate that any or none of the options can be used in any 
sequence but none of the elements may appear more than once. For example: 



Choose A,B,C, or C,A, or B, etc. 
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Conventions Used (continued) 



NOTATION DESCRIPTION 

... A horizontal ellipsis in a syntax statement indicates that a previous element can be 

repeated. For example: 

[ ^itemname] . . . ; 

A vertical or horizontal ellipsis may also denote omission or repetition. 

i| A shaded delimiter preceding a parameter in a syntax statement indicates that the 

delimiter must be supplied whenever (a) that parameter is included or (b) that pa- 
rameter is omitted and any other parameter that follows is included. For example: 

itema[§itemb] [^itemc] 

means that the following are allowed: 

itema 

itema^itemb 
itema ^itemb ^itemc 
itetna^ ^itemc 

A When necessary for clarity, the symbol A can be used in a syntax statement to indi- 

cate a required blank or an exact number of blanks. For example: 

SET [ (modifier) j^ioariable); 

underlining When necessary for clarity in an example, user input can be underlined. For 

example: 

NEW NAME? ALPHA 

In addition, brackets, braces or ellipses appearing in syntax or format statements 
that must be entered as shown will be underlined. For example: 

LET i)ar[[subscript]]=value 

shading Shading represents inverse video on the terminal screen. Shading is also used to em- 

phasize key portions of an example. 



[ 1 The symbol 1 1 indicates a key on the terminal keyboard. For example, 

[RETURNI indicates the RETURN key. 

[coNTROLl c^ar Control characters are indicated by [cqntrolI followed by the character. For ex- 

ample, [CONTROLI Y means hold the CONTROL key and press Y simultaneously. 



16 



Reader Comment Sheet 

Information Networks Group 

LAN3000/V Diagnostic and Troubleshooting Guide 

30242-90003 August 1987 

We welcome your evaluation of this manual. Your comments and suggestions help us to improve our 
publications. Please explain your answers under Comments, below, and use additional pages if necessary. 

Is this manual technically accurate? 

Are the concepts and wording easy to understand? 

Is the format of this manual convenient in size, arrangement, and readability? 

Comments: 



Yes 


No 


Yes 


No 


Yes 


No 



This form requires no postage stamp if mailed in the U.S. For locations outside the U.S., your local com- 
pany representative will ensure that your comments are forwarded. 

FROM: Date 

Name 

Company 

Address 



FOLD FOLD 



NO POSTAGE 

NECESSARY 

IF MAILED 

IN THE 

UNITED STATES 



BUSINESS REPLY MAIL 

FIRST CLASS PERMIT NO. 256 ROSEVILLE, CALIFORNIA 




POSTAGE WILL BE PAID BY ADDRESSEE 

Publications Manager 
HEWLETT-PACKARD COMPANY 
Roseville Networks Division 
8000 Foothills Boulevard 
Roseville, California 95678-6598 

FOLD FOLD 




General Information 



1 



Introduction 



An IEEE 8023 Local Area Network (LAN) presents a relatively complex 
hardware troubleshooting environment. The connection of one computer system 
(i.e., node) to another may involve many hardware components. 

Figure 1-1, for example, shows four HP 3000 MPE-V systems connected together 
on different LANs or LAN segments. Each system connection requires hardware 
that depends on the type of LAN cable. Furthermore, various combinations of 
Hubs, Bridges, and Repeaters are used to extend or join the individual LANs. 

As the network grows, network troubleshooting becomes more complex. 
Additional systems (such as HP 9000s, HP 1000s, personal computers, or other HP 
3000s), cabling, and LAN extension hardware provide additional sources of 
network faults. 
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Figure 1-1. LAN Hardware Troubleshooting Complexity 



General Information 
I-l 



Various tools are available on MPE-V systems to assist in the LAN 
troubleshooting process. As they pertain to LAN troubleshooting, the following 
tools are described in this manual: 

• SHOWCOM: for monitoring the communication line. 

• Activity LEDs: for monitoring activity on AUI or StarLAN node cabling, 
and on the LANIC card. 

• LANDIAG: the LAN Diagnostic program for testing composite LAN link 
hardware. 

• Self Test and selftest LEDs: primarily used for testing the LANIC card 
circuitry. 

• Tracing: for analyzing protocol activity of the network at the link level. 

• Memory Dump: for analyzing a system crash in relation to a LAN 
problem. 

• NSDPAN5/NSDUMPJ: for formatting memory dumps. 

• LISTL0G5: for analyzing the system log. 

• NMMAINT: for analyzing the NMS log. 

• CSLIST: for checking the version of communications software. 

• DSLIST: for obtaining a list of DS software module versions. 
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Applicable Networks 



Coaxial Cable LANs 



Twisted Pair LAN 



The tools provided in this guide are described as they pertain to troubleshooting 
LANs that conform to Hewlett-Packard implementations of the IEEE 802.3 
standards. These LANs feature baseband signaling, and a Carrier Sense Multiple 
Access with Collision Detection (CSMA/CD) network access protocol. 



Hewlett-Packard coaxial cable LANs feature lO-megabit per second burst 
transfer rates over a coaxial cable bus to which each node attaches. 

IEEE 802.3 Type 10BASE5 Standard 

This LAN uses a "thick" (0.4 inch/10 mm diameter) coaxial cable. Thick cable 
LANs feature connection of up to 100 nodes on a single 500 metre bus segment. 

HP 3000 MPE-V systems connect to this LAN using the HP LAN3000/V link 
product. Hardware included with this product consist of a Local Area Network 
Interface Controller (LANIC) interface card, an Attachment Unit Interface 
(AUI) cable, and an HP 30241 A Medium Attachment Unit (MAU) and tap 
assembly for cable access. 

IEEE 802.3 Type 10BASE2 Standard 

This LAN uses a "thin" This LAN uses a "thin" (0.19 inch/4.9 mm diameter) RG58 
C/U coaxial cable. ThinLAN cables feature connection of up to 30 nodes on a 
single 185 metre bus segment. 

HP 3000 MPE-V systems connect to this LAN using the HP ThinLAN3000/V 
link product. Applicable hardware consists of the LANIC interface card, and HP 
28641 A ThinMAU and BNC tee connector for cable access. 



IEEE 802.3 Type 1 BASES Standard (Proposed) 

The Hewlett-Packard twisted pair cable LAN, HP StarLAN, features a 1-megabit 
per second burst transfer rate through a hierarchical structure of HP 272 12 A 
StarLAN Hubs. Nodes connect to the Hubs via the twisted pair cables; each 
cable can be up to 250 metres in length. 

HP 3000 MPE-V systems (Series 37 and MICRO 3000 systems only) connect to 
this LAN using the HP StarLAN3000/V link product. Applicable hardware 
consists of the interface card, and twisted pair cable ordered separately. 
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Fault Isolation and Repair Strategy 



LAN hardware faults must be located and corrected. Because LANs are 
comprised of many pieces of hardware, faults must identified to the field 
replaceable unit (FRU) level of assembly. If the faulty FRU cannot be 
immediately corrected, it is replaced with a new or functional unit. (For repair, 
replacement, or return procedures, consult the installation or service manual for 
the failed unit.) 

LAN faults can be classified into two categories: Node faults, and Network 
faults. A Node fault is characterized by a single node failure that does not 
affect the other nodes on the network. A Network fault is characterized by 
multiple node failures, where it is likely that a piece of hardware used commonly 
by the nodes has failed. Fault isolation procedures for both types of faults are 
needed. 

The following manuals provide both node and network fault isolation 
procedures. They are differentiated by the type of network to which they apply. 

- For coaxial cable LANs, refer to the LAN Link Hardware Troubleshooting 
Manual 5955-7681. (HP CE Handbook version, 5959-2217.) 

- For HP StarLAN, refer to the HP Star LAN Diagnostics and Troubleshooting 
Guide for PCs, 50906-90060. 

Appendix A of this guide provides fault isolation procedures, in flowchart 
format, for HP 3000 MPE-V links. Although network considerations are not 
excluded, these procedures focus on MPE-V link Node faults. They complement 
the above troubleshooting manuals by providing an alternative set of procedures 
that use more features of the tools described in this guide. 
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Network Map 



When troubleshooting a network, the availability of a network map will be 
critical, especially for large complex networks. As required by Hewlett-Packard, 
the network map should have been developed during the configuration of the 
network, and maintained to reflect any growth or modification. 

A network map provides the physical layout of nodes on the network, including 
distances from one to another. Physical layout means the placement of all 
cables MAUs and Taps, Hubs and all related network computer equipment. In 
addition the network map should be labeled with relevant node information, 
including node names, globally administered station addresses, and any locally 
administered station addresses. The configuration of relevant network software 
on each node would be helpful. 

If a network map is not available, you should make one. Refer to the 
NS3000/V Network Manager Reference Manual (Volume 1, 32344-90002; 
Volume 2 32344-90012) for information on addresses and other configured items 
included in the network map. Also, refer to the HP SiteWire Planning Guide 
(5959-2201) for additional information. 
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Abbreviations and Nomenclature 



You may find the following terminology useful when reading this guide. 



AUI 

Bridge 

Coax 

CR-SR 

CRC 

DMA 

DRT 

FRU 

Heartbeat 

1MB 

I/O 

Hub 

Jabber 

LAN 



Attachment Unit Interface. 

Address filtering device connecting different LANs, 
such as coaxial cable LAN to coaxial cable LAN, or 
coax cable LAN to twisted-pair cable LAN. 

Coaxial cable medium for 802.3 networks. 

Control Register - Status Register. 

Cyclical Redundancy Check, 

Direct Memory Access. 

Device Reference Table. 

Field Replaceable Unit (e.g. interface card, or cable 
section. 

After successful frame transmission, a short collision 
indicator test signal. 

Inter-Module Bus, the bus supporting I/O in HP 3000 
systems (Series 4X/5X/6X/70). 

Input/Output. 

A central device to which multiple cables (hence nodes) 
connect, e.g., StarLAN Hub, ThinLAN Hub. 

Excessive LANIC transmission. A jabbering node 
prevents other nodes from gaining access to the 
network medium. 

Local Area Network. 
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LANIC 

LED 

Loopback 

MAU 

MAUPON 

MAUPS 

MC 



Local Area Network Interface Controller for IEEE 
802.3 LAN I/O (the interface card in HP 3000 MPE-V 

systems). 

Light Emitting Diode. 

Transmission and receipt of data to verify operation of 
the communication path. 

Medium Attachment Unit, a device that provides the 
LANIC with access to a coaxial cable medium. 

MAU Power On signal. 

MAU Power Sense signal. 

A multicast message; a type of broadcast message sent to 
a group of stations, but not necessarily to all the stations. 



Monitor 

NMI 

MPU 

Node 

NS 

OBII 

RNT 

SIMB 

SPU 
STREG 

Twisted-pair 



RAM resident Z80 code used together with the self test 
in order to upload detailed test results to the HP 3000. 

Non-Maskable Interrupt. 

A Z80 microprocessor on the LANIC. 

Uniquely addressable station on a LAN. 

HP Network Services for the HP3000. 

Obtain Interrupt - An IMB/SIMB command. 

Remote Node Test. 

Synchronous Inter-Module Bus, the bus connecting the 
CPU, Memory, and I/O in HP 3000 Series 37 and 
MICRO 3000 systems. 

System Processor Unit on HP 3000. 

Self Test Register. 

Twisted-pair cable for IEEE 802.3 networks. 
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SHOWCOM 



The SHOWCOM command is a useful tool for monitoring the status of a line while 
it is in use. To use SHOWCOM, you normally must have operator (OP) capability, 
and you must be on the system console. 



Syntax 



: SHOWCOM xxx [;ERRORS] [;RESET] 



Where xxx indicates the logical device (Idev) number of a Communication 
System (CS) device, i.e., the LANIC card. 

The ERRORS option causes SHOWCOM to display all available information. RESET 
causes all fields to be reset to zero after they are displayed. 

For example: 



: SHOWCOM 100; ERRORS 



TRANSMIT LDN 

MESSAGES SENT 7364 

COLLISIONS 

EXC COLLISION ERRS 30 

UNDERRUNS 

CLR TO SEND LOSSES 



100 RECEIVE 

MESSAGES RECVD 9941 
BCC/CRC ERRORS 
BUFF OVERFLOWS 3676 
OVERRUNS 
LENGTH ERRORS 



# OF RECOVERABLE ERRORS 32 
LAST RECOVERABLE ERROR 6 

# OF IRRECOVERABLE ERRORS 4 
LAST IRRECOVERABLE ERROR 201 
LINE IS CONNECTED 



SHOWCOM 
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Interpreting Results 



Transmit Fields 



MESSAGE SENT 



This is the number of frames that the HP 3000 gives 
to the LANIC, and is not necessarily the number of 
frames that were actually transmitted onto the LAN 

When this value increases with time, it means that the 
driver continued to give frames to the LANIC card 
whether or not the frames were successfully 
transmitted. 

This number will include protocol reply frames, such 
as those in response to XID or TEST frames received 
from a remote node. Such response frames are 
internal to the driver/firmware and are counted even 
though the responses were transparent to higher level 
processes. 



COLLISIONS 



EXC COLLISION 
ERRS 



This is the number of times that the LANIC card 
experienced a collision on transmit. A large number 
here may mean excessive network traffic, a topology 
violation (e.g., excessive distances), or excessive jitter. 
On a coaxial cable LAN, the local MAU/ThinMAU 
may be faulty, or a remote MAU/ThinMAU may be 
"leaky." On a StarLAN, a Hub or LANIC card may 
be faulty. 

This statistic is incremented if, after 16 collisions, a 
frame was not successfully transmitted onto the 

LAN. 



UNDERRUNS 



CLR TO SEND 
LOSSES 



The LANIC card transmits data onto the line at a 
high rate. This field shows the number of times, if 
any, that data could not be transmitted onto the line 
at the required rate. 

Not meaningful for the LANIC card (applies to INP 
interface card). 
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Receive Fields 



MESSAGES RECVD 



This includes frames actually passed from the LANIC 
card to the 3000. Errors detected by the LANIC that 
do not cross the LANIC-to-HP 3000 boundary are 
not included. Therefore, frames with length or CRC 
errors, and multicast frames that do not pass the 
LANIC card's filtering algorithm are not counted. 
However, protocol frames that are received do pass 
across the LANIC-to-HP 3000 boundary and are 
therefore counted in this statistic. 



BCC/CRC ERRORS 



A frame was received with bad checksum (CRC). 
This is an indication that a bit error probably 
occurred. Since the bit error rate is supposed to be 
very close to zero, a large number here is probably 
cause for concern. On a coaxial cable LAN, there 
may be excessive jitter, too many nodes, nodes not 
properly spaced on the cable, improper AUI cables, 
cables of low quality, bad MAU, or bad LANIC. On 
StarLAN, there may be excessive jitter, excessively 
long or poor quality cables, a bad Hub, or bad 
LANIC. 



BUFF OVERFLOWS 



This means we received a frame but didn't have a 
buffer to put it into. A large number here probably 
means that too few receive buffers were configured, 
too few "maximum reads outstanding" were 
configured, or the system is too busy or has too little 
real memory. The number of buffers probably needs 
to be increased. 



OVERRUNS 



Incremented for every inbound frame for which the 
LAN controller chip attempted to write a data word 
to memory. It was delayed so long by the bus latency 
that inbound data was lost (the FIFO on the LANIC 
card overflowed). A large number here means we 
have too much bandwidth of the IMB/SIMB utilized. 
This may mean that too many high-speed channels 
are connected on the same IMB/SIMB. 



LENGTH ERRORS 



Incremented for every frame where the length-field 
in the 802 frame does not match the number of bytes 
actually received. This also includes frames over 
1522 bytes in length (including FCS, frame check 
sequence field). A very large number here probably 
indicates that a non-802.3 compatible node (e.g., 
Ethernet) is transmitting, or that there is some bad 
hardware transmitting to us. There could also be 
someone transmitting frames longer than 1522 bytes. 
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Errors 



# OF RECOVERABLE 
ERRORS 

LAST RECOVERABLE 
ERROR 



# OF IRRECOVERABLE 
ERRORS 



LAST IRRECOVERABLE 
ERROR 



The number of errors reported by the driver that did 
not cause the link to be disconnected. 

This gives the last non-zero CS error number returned 
by the driver. The completion status can be anything 
other than IRRECOVERABLE ERROR (completion 
status 3) or CATASTROPHE (completion status 5). 
This includes CS "recoverable error codes" as well as 
error numbers that are normally "irrecoverable error 
codes" but were completed with good status so as not 
to cause the translator to shut down the link. 

The number of errors that would force the link to be 
disconnected, e.g., on a coaxial cable LAN, could not 
turn on MAU/ThinMAU power. 

This is the last non-zero CS error code that the driver 
gave when it completed a request with 
IRRECOVERABLE ERROR (completion status 3) or 
CATASTROPHE (completion status 5). 

This will not be updated for CS error codes 63 and 
64, since these are not really "errors" but are normal 
completion codes for ABORT 10 (function code 66), 
generated on all process terminations (called from 
EXPIRE), and the HARD ABORT, generated when 
the translator detects other errors. 



The line will always be in any one of four states: ^ 



(1) CONNECTED 

(2) DISCONNECTED 

(3) CLOSED 

(4) UNDEFINED 



The driver is active, firmware has been downloaded 
and command and response queues have been 
initialized. Basically, the driver and hardware are 
ready to receive and transmit frames. 

The driver and hardware have not finished 
initializing or an irrecoverable error has occurred. 
Basically, the driver and hardware are not ready to 
receive and transmit frames. 

The LDEV is not allocated (not in use). 

Software error. 
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Activity LEDs 



There are 15 LEDs located on the edge of each LANIC card. Figures 3-1 and 3-2 
show the LED locations for Series 4X/5X/6X/70 and Series 37/MICRO3000 
systems, respectively. 
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Figure 3-1. LANIC Card LEDs On Series 4X/5X/6X/70 Systems 
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Figure 3-2. LANIC Card LEDs On Series 37 and MICRO3000 Systems 



Each of the 15 LEDs is labeled with different labels. The single alphabetic labels 
provide a quick reference to the LEDs. In addition, one- and two-letter 
mnemonics are provided to remind users of the LED function. The labels and 
functions of the LEDs are shown in Figure 3-3. 
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The LEDs can be classified into the following groups: 



• Cable Interface Activity LEDs. The seven LEDs on the left, labeled "A" 
through "G", monitor activity on the cable, hence the network. 

• MPU Activity LEDs. During normal operation, the eight LEDs on the 
right ("H" through "N" plus "*") monitor LANIC card MPU activity. 
However, these LEDs are also used by card self test (refer to Chapter 5). 
When used by self test, LED mnemonics do not apply. 
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Figure 3-3. LED Labels and Functions 



Table 3-1 provides a descriptive summary of the LEDs during normal operation. 
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LED 



Table 3-1. LED Description During Normal Operation 



Mnemonic 



VP 



CL-E 



CL-L 



DO-E 



DO-L 



CR-E 



CR-L 



TX 



RX 



DL 



RO 



IT 



ST 



Description 



For Coaxial Cable LAN: ON when power is available to the 

MAU/ThinMAU. 
For StarLAN: Not used, always OFF. 



ON when the collision line goes active. 



ON for steady collision detect signal from the Manchester 
encoder/decoder. 



ON when the Data Out signal from the Manchester encoder/ 
decoder goes from false to true. 



ON if there is a steady Data Out signal from the Manchester 
encoder/decoder. 



ON when the carrier sense signal from the Manchester encoder/ 
decoder goes from false to true. 



ON if there is a steady carrier sense signal from the Manchester 
encoder/decoder. 



ON when the card is processing and transmitting a frame. 



ON when the card is processing a frame addressed to this node. 



ON when the card is monitoring all link activity, or is monitoring 
activity sent to a particular address not its own. 



ON when the download command is received from the SPU to 

download operating firmware. 
OFF when the SPU commands the MPU to begin executing the 

download feature. 



ON when ROM-resident firmware is being executed by the MPU; 
OFF when RAM-resident (downloaded) firmware is being executed. 



ON when the MPU is quiescent (waiting for a host command or I/O 
completion), during which it checks for activity needing attention. 



ON when the MPU is executing an idle test of internal card 
circuitry, during which the MPU tests card hardware that will not 
affect the readiness to process frames. The idle test also runs 
before the node becomes operational on the link. 



ON when the MPU is executing ROM-resident self test. When ST is 
lit, LEDs H through N are selftest progress and failure indicators, 
rather than as defined above. 
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Cable Interface Activity LEDs 

The cable interface LEDs monitor the four functions shown below: 



DO Data out. These LEDs are ON when data is transferred from 

this LANIC onto the Data-Out/Transmit signal pair. 

CL Collision detect. On a coaxial cable LAN, these LEDs are ON 

when a collision is detected by the MAU/ThinMAU on this 
node. For receiver-based collision detection devices, collisions 
are monitored continuously (whether transmitting or not) - 
the CL LEDs indicate virtually every collision that occurs on 
the coaxial cable. For transmit-based collision detection 
devices, the CL LEDs indicate collisions that occur only when 
transmitting. 

Note that the CL LEDs are blocked from lighting during the 
IEEE 802.3 SQE heartbeat signals, which occur after each 
transmission. 

On a StarLAN, these LEDs are ON when a collision pattern is 
output by the Hub to which this node is connected. The CL 
LEDs will be active whether or not the LANIC is 
transmitting. (Heartbeat signals are not employed on 

StarLAN.) 

CR Carrier sense. These LEDs are ON when data is detected 

coming into the node on the Data-In/Receive signal pair, or 
when the collision function is detecting collisions. For coaxial 
cable connections, the CR LEDs do not light for SQE 
heartbeat signals (StarLAN connections do not employ 
heartbeat). 

VP Voltage plus. For coaxial cable connections, this LED is 

connected through a current limiting resistor directly to the 
VP AUI lead. When ON, it indicates power (+12V) is 
available to the MAU/ThinMAU. 

For StarLAN connections, this LED is not used and is always 
OFF. 
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The E and L Indicators 



Each of the DO, CL and CR functions consist of a pair of LEDs, labeled E and 
L (for Edge and Level, respectively). The pair is driven in such a manner that all 
conditions of activity -- from occasional isolated events to continuous events - 
are visually distinguishable. The LEDs are encoded as follows: 

- "E" LED. Turns ON each time a monitored event begins. It remains ON for 
6 milliseconds regardless of the length of the event. 

- "L" LED. Turns ON at the beginning of the event and turns off at the end 
of the event. 

Following this algorithm, a single isolated event of short duration produces a 6 
millisecond blink of the E LED, and the L LED is on for the length of the event, 
which is short. Therefore, the L LED appears to remain off. 

As the frequency of events of short duration increases, the E LED appears to be 
constantly illuminated, and the L LED begins to glow. 

When short duration events occur constantly, both the E and L LEDs will appear 
to be constantly illuminated. 

A single event of very long duration produces a single 6 millisecond blink of the 
E LED at the beginning of the event, and the L LED turns on and stays on for a 
long time, until the event is completed. 

Events that continue for a "very long" time will cause the E LED to blink at the 
beginning of each event for 6 milliseconds, and the L LED will appear to be 
constantly illuminated. 

Events on a normally-operating network are all of short duration. For reference, 
see Table 3-2. 
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Table 3-2. Approximate Duration References 



Event 


Approximate Duration 


Coaxial Cable 


StarLAN 


Maximum frame length transmission 


1.2 ms 


12 ms 


Minimum frame length transmission 


0.051 ms 


0.51 ms 


Collisions 


0.049 ms 


0.49 ms 



For events of short duration, such as those in Table 3-2, note the following: 

- As the frequency of activity increases, the frequency of flashing of the E 
LED increases while the L LED is off or very dim. 

- When the frequency of activity is very high, and the E LED appears to be 
ON continuously, the L LED indicates further increase in activity by 
becoming brighter and brighter until it reaches full intensity. This state of 
the E and L LEDs indicates continuous short events. 



Relationship to Cable Signals 



To understand the indications given by the DO, CL and CR LEDs, it is necessary 
to understand how the signals that drive these LEDs are related to the lines of 
the attached cables. 

For coaxial cable LAN connections, the HP AUI cable contains three signal pairs 
used by the MAU/ThinMAU: the Data-Out pair, the Data-in pair, and the 
Control-In pair. 

For StarLAN connections, the HP StarLAN cable contains two signal pairs: the 
Transmit pair, and the Receive pair. The Receive pair is used for frame 
reception and collision signals. 
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DO LED Events 

The event indicated by the DO LEDs is the enabling of the data encoder by the 
protocol controller on the LANIC. The event begins when the encoder is turned 
on. While the encoder is on, a continuous stream of encoded data bits is 
transmitted by the LANIC onto the Data-Out/Transmit signal pair. The event 
ends when the data encoder is disabled. When the encoder is disabled, data bits 
are no longer sent onto the Data-Out/Transmit pair. 

The transmission of a single frame onto the cable Data -Out/Transmit pair is one 
event, and will cause the E LED to blink ON for 6 ms. The L LED will be 
illuminated for the length of time required to transmit the data bits onto the 
Data-Out/Transmit pair. 



CL LED Events 

The event indicated by the CL LEDs is the occurrence of the Signal Quality 
Error (Collision) signal on the Control-In/Receive pair of the attached cable. 
The event begins when the first transition of the collision SQE signal is received 
at the LANIC, and ends 200 nanoseconds after the last transition is received. 

Coaxial Cable LAN Connection . On collision detection, the MAU/ThinMAU 
sends the SQE signal (a 10 MHz signal) to the LANIC on the Control-In pair of 
the AUI cable. 

The SQE heartbeat, a short burst of 10 MHz signal returned on the Control-In 
pair after each successful transmission, is used to test the collision detection 
circuitry. SQE heartbeat does not cause the CL-E LED to blink. For a period of 
5.3 microseconds after a successful transmission, the CL-E LED is blocked from 
collision signals. Therefore, heartbeat and normal collisions that occur during 
this period will not activate the CL-E LED. 

Heartbeat will cause the illumination of the L LED for approximately 1 
microsecond; however, this is too short to be seen. 

StarLAN Connection . On collision detection, the StarLAN Hub to which the 
LANIC is connected sends a Collision Presence Signal (CPS) - a 1 MHz signal ~ 
to the LANIC on the Receive pair of the StarLAN cable. 

Heartbeat signals are not used on StarLAN. Note that software used to monitor 
card statistics may increment heartbeat errors. Such errors should be disregarded 
when they occur with a StarLAN card. 
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MPU Activity LEDs 



CR LED Events 

There are two events indicated by the CR LEDs: 

- Reception of data on the Data-In/Receive Hnes of the attached cable, or 

- Occurrence of a collision signal as described above (see "CL LED Events"). 

The event begins when the first data transition arrives on the Data-In/Receive 
pair, or when the collision event begins, whichever occurs first. The event ends 
200 nanoseconds after the last data transition on the Data-In/Receive pair, or 
after the collision event ends, whichever occurs last. 



When the LANIC card has been reset either by power-up of the system or by the 
operating software, all eight of the MPU activity indicators (LEDs "H" through 
"N" and "*") will be on continuously. This indicates that the MPU is not 
executing. 

The cable interface LEDs will all be off. For coaxial LANs, this includes the VP 
LED, indicating the MAU/ThinMAU is not powered. 

After the LANIC has successfully passed self test (see Chapter 5), the "*" LED 
will be OFF, and the other seven MPU activity LEDs will now indicate MPU 
activity. When the "*" LED is OFF, the "H" through "N" LEDs should be 
interpreted according to their two-letter mnemonics. 

When self test passes, the system processor unit (SPU) is interrupted and notified 
of the event. Between the time that this interrupt is given and the time when the 
SPU begins to access the LANIC, the "RO" and "Q" LEDs will be illuminated. 
This indicates that the LANIC is executing ROM code and is quiescent, while 
waiting for the SPU to take control. (For coaxial LAN connections, the VP LED 
will be illuminated, indicating that the MAU is powered.) 

Any activity on the network will be reflected by the state of the CL and CR 
LEDs. The LANIC will never transmit in this state, and therefore, the DO LEDs 
will remain inactive. 



Activity LEDs 
3-9 



On command from operating software, the SPU prepares the LANIC for 
operation. It must first download the operating firmware from system memory 
to the LANIC When this process begins, the "DL" LED turns ON, and the "Q" 
and "IT" LEDs will extinguish. After each download command, the "Q" LED 
lights for a few milliseconds. At least 7 download commands occur, but they 
may not be separately distinguishable. Note that the pattern that occurs on one 
working system will occur on all other working systems. So if you are suspicious 
of this process on your system, compare the download pattern on the suspect 
system with a system that works. 

After the download is complete, the SPU will instruct the MPU to begin to 
execute the downloaded firmware. When this occurs, the "RO" and "DL" LEDs 
will extinguish. The "Q" and "IT" LEDs will turn ON. 

A short time later the SPU will instruct the LANIC to set its individual node 
(station) address. When this occurs, the LANIC performs a duplicate address 
check, which is accomplished by transmitting 10 self -addressed frames onto the 
network with a 500 ms separation between frames. The "TX" and "DO-E" LEDs 
will both turn ON for each of the 10 frames. In addition, the "CR-E" LED will 
indicate that the frames were sent onto the coax and caused carrier to come on. 
If collisions occur, frame transmission will be retried up to 15 times each, with 
the resultant activity indicated on the "CL" LEDs. 

Because the frames are self -addressed, the "RX" LED should not light during the 
duplicate address check. If the "RX" LED does light, it is due to a frame 
received from a remote node. This may occur, for example, if a duplicate station 
exists, or an ordinary frame is addressed to the local LANIC. 

If a reply to the duplicate address check is received, the duplicate address check 
fails. No further check frames will be sent. The system software will close the 
link and clear the LANJC, forcing all the LANIC card activity LEDs to turn ON 
and stay ON. The LEDs will indicate extended idle self test in progress. 

If the duplicate address check passes, the link is opened, and frame transmission 
and reception will commence. The LEDs will indicate activity as it occurs. 

Presuming the network and LANIC card are idle prior to a transmit request 
from the SPU to the LANIC card, frame transmission should behave as follows 
during normal network operation: 
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While idle, "Q" and "IT" LEDs are ON. For coaxial LAN connections, the 
"VP" LED is ON. 

When the MPU begins processing the transmit command, the "Q" and "IT" 
LEDs will extinguish, and the "TX" LED will light. The LANIC begins the 
transmit process by reading the frame from system to on-card memory. 

Once the frame is in LANIC card local memory, and the network is free, the 
serial transmission process begins. This causes the "DO-E" LED to light. The 
"DO-L" LED will also light for the duration of the frame transmission, but 
this may or may not be visible depending upon the length of the individual 
frame being sent. 

For coaxial LAN connections, the serial data reaches the MAU/ThinMAU 
and is transmitted onto the coaxial cable. The MAU/ThinMAU receives its 
own signal off of the coax, and sends it back down the AUI cable on the 
Data-in signal pair. 

For StarLAN, the serial data is transmitted on the StarLAN cable. The Hub 
receives the data and sends it down the Receive signal pair. 

The LANIC card detects data arriving on the Data-In/Receive pair of the 
attached cable, resulting in the "CR-E" LED turning ON. The "CR-L" LED 
will also be illuminated for the duration of the frame, but this may or may 
not be visible. If the "DO-L" LED is visible, the "CR-L" LED will also be 
visible for approximately the same length of time. 

If no collision is encountered, the "CR-E" and "DO-E" LEDs will go OFF 
after 6 milliseconds, followed quickly by the "TX" LED going OFF, and the 
"Q" and "IT" LEDs turning ON. 

If a collision is encountered, the "CL-E" LED will turn ON, and up to 15 
additional attempts to transmit the frame will occur. From the 
retransmission attempts, the "DO" and "CR-E" LEDs may appear to be ON, 
and the "DO" and "CR-L" LEDs will probably appear to be partially 
illuminated. The intensity of the "-L" LEDs will be determined by frame 
length, the number of retransmissions, and the time separation of the 
retransmissions. The "CL" LEDs will also display behavior similar to the 
"CR" and "DO" LEDs if multiple retransmissions are required before the 
frame is successfully transmitted. 

In the collision case, it must be remembered that other network activity may 
also cause the "CL" and "CR" LEDs to light, and the activity caused by the 
LANIC will be superimposed upon the network activity being displayed in 
the "CR" and "CL" LEDs. 
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Network Fault LED Examples 



This section provides examples of LAN faults and the resulting display of a 
LANIC card's cable interface activity LEDs. 

We presume that the LANIC card is enabled for operation on the network and 
the LANIC card driver is turned on. This can be verified by the SHOWCOM 
command (see Chapter 2): the line must be "CONNECTED". 



NOTE 



The LANIC card LEDs will not reflect network activity if the line is not 
CONNECTED. For some faults, system software may shut down and reset the card, 
resulting in a DISCONNECTED line. 



Coaxial Cable LAN 



Due to hardware differences, coaxial cable connection faults differ from 
StarLAN connection faults. 



The following faults and cable interface activity LED displays pertain to coaxial 
cable LAN connections. 



Open Tap 

If the tap on the coax is not making contact with either the center conductor or 
shield, the LEDs will indicate no network activity. 

When the LANIC tries to transmit, a collision will occur. Thus, the DO-E, CR-E 
and CL-E LEDs will all light. 
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Open Coax 

Open coax faults include missing or loose terminators, loose barrel connectors, or 
even breaks in the cable. For open coax faults, attempted transmission by any 
node attached to the cable will result in a collision. For nontransmitting nodes, 
the CR-E and CL-E LEDs may light. For transmitting nodes, the DO-E, CR-E 
and CL-E LEDs will light. 

Note that, unlike an open tap fault where only the single node is affected, all 
HP 3000 nodes connected to the open coax cable will display these symptoms. 



Shorted Coax 

For a shorted coax, the voltage associated with any transmission attempt will be 
clamped to zero (loss of carrier). If the coax is shorted close to the 
MAU/ThinMAU, the CR-E and DO-E LEDs will flash when the node attempts 
to transmit. 



Short On MAU/ThinMAU Power Circuit (VP) 

If there is a short on the power lines going to the MAU/ThinMAU, the LANIC 
overcurrent protect switch will turn the power off, and the VP LED will turn 
OFF. If this occurs during the self test, a failure code, 24H, will result. 

If the short occurs during normal operation of the board, card firmware will 
attempt to turn the power back on. This may occur up to 20 times. If this fails, 
the firmware will report a fatal error to the driver and enter a soft reset state in 
which the RO and Q LEDs will be lit. When the upper level software recognizes 
the fatal error, it will do a hard reset on the card, leaving LEDs "H" through "*" 
lit. 



Continuous Transmission From a Remote Node 

If some other node is transmitting continuously, and its MAU/ThinMAU fails to 
terminate its transmission, the local LANIC card will detect carrier. Thus, its 
CR-L LED will be ON. 



Constant Collision on the Network 

Excessive voltages on the coax are interpreted as collisions, for example, when 
multiple transmissions simultaneously exist on the cable, or a faulty 
MAU/ThinMAU is leaking a DC voltage onto the coax. The local 
MAU/ThinMAU detects such voltages and actuates the Control-IN (CI) signal 
line. This will cause the CL-L and CR-L LEDs to turn ON. 
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open or Shorted Data Out Signal Lines 

If the Data Out signal pair in the AUI is open or shorted, the LANIC will not be 
able to transmit During transmit attempts, the DO-E LED will flash. However, 
since no transmission occurs, carrier will not be detected and the CR LEDs will 
not turn on. 

Note, however, that the LANIC will be able to receive frames. Received frames 
will light the CR LEDs. 



Open or Shorted Dl Pair in AUI 

If the Data-in signal pair is disabled due to a short or a open, normal network 
activity will not be detected by the CR LEDs. 

However, the CR LEDs are lit for collision signals on the Control-In signal pair, 
so a collision will cause the CR-E LED along with the CL-E LED to blink ON. 



External Loopback 

Table 3-3 provides possible causes of network errors based on cable activity 
LEDs that turn ON during a transmit. A transmit can be invoked by conducting 
a loopback test. Test 14, of the LAN Node diagnostic (LANDIAG3000/V). See 
Chapter 4. 



NOTE 



The causes listed should not be construed as being complete. They only serve as 
suggestions on where to look for possible faults. Note that only single faults are 
presumed. Multiple faults may result in other symptoms. 



Activity LEDs 
3-14 



Table 3-3, AUI Cable Activity LEDs and Possible Causes on Transmit 



StarLAN 



LEDs that 
Turn ON 
During Loopback 


Possible Causes from 
a Single System 


Possible Causes from 
Multiple Systems 


NONE 


Bad LANIC 




DO only 


Bad AUI or connection; 
Bad MAU; 
Bad LANIC; 
Shorted Coax 


Shorted Coax 


DO and 
CR 


Bad MAU; 
Bad LANIC; 
Bad Coax 


Bad Coax 


DO and 
CR and 
CL 


Bad Tap; 

Bad terminator; 

Bad barrel 


Bad terminator; 
Bad barrel 


VP not lit 


Shorted AUI; 
Bad MAU; 
Bad LANIC 





The following faults and symptoms pertain to HP StarLAN connections. 



Bad Hub 

If the StarLAN Hub is not able to process network traffic, neither collisions nor 
frames will be sensed by any LANIC card. Each card's CR or CL LEDs will be 
OFF. 

If any LANIC transmits, the the Transmit line will be active and the DO-E LED 
will light. 

Note that these symptoms apply to all HP 3000 nodes connected to the Hub. 
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Bad Connection 

If the cable is not mated properly at each end, or the cable is severed, the 
symptoms are the same as for a bad Hub, but apply only to the affected node. 



Open or Shorted Transmit Pair 

If the cable's transmit pair is open or shorted, the LANIC will not be able to 
transmit. During transmit attempts, the DO-E LED will flash. However, since no 
transmission occurs, carrier will not be detected and the CR LEDs will not turn 
ON for this attempted transmission. 

Note, however, that the LANIC will be able to receive frames and detect 
collisions. These events will light the CR and CL LEDs. 



Open or Shorted Receive Pair 

If the receive signal pair is disabled due to a short or open, normal network 
activity will not be detected by the CL or CR LEDs. 

Continuous Transmission From a Remote Node 

If some other node is transmitting continuously and its Hub fails to terminate its 
transmission, the local LANIC card will detect carrier via the receive signal pair. 
Therefore, the CL-L and CR-L LEDs will turn ON. 



Constant Collision on the Network 

For StarLAN, the Hub generates collision signals and disseminates them on the 
receive signal pair. If collision signals are constant, the the CL-L and CR-L LEDs 
will be ON. 
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External Loopback 

Table 3-4 provides possible causes of network errors based on cable activity 
LEDs that turn ON during a transmit. A transmit can be invoked by conducting 
a loopback test, Test 14, of the LAN Node diagnostic (LANDIAG3000/V). See 
Chapter 4. 



NOTE 



The causes listed should not be construed as being complete. They only serve as 
suggestions on where to look for possible faults. Note that only single faults are 
presumed. Multiple faults may result in other symptoms. 



Table 3-4. StarLAN Cable Activity LEDs and Possible Causes on Transmit 



LEDs that 

Turn ON 

During Loopback 


Possible Causes from 
a Single System 


Possible Causes from 
Multiple Systems 


NONE 


Bad LANIC 




DO only 


Bad Hub; 
Bad Cable 


Shorted Coax 


DO and 
CR 


Bad Hub; 
Bad LANIC; 
Bad Cable 


Bad Hub 


DO and 
CR and 
CL 


Bad Hub; 
Bad LANIC 


Bad Hub 


VP not lit 


Shorted AUI; 
Bad MAU; 
Bad LANIC 
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LAN Node Diagnostic 



General Information 



This chapter describes the LAN Node Diagnostic as a tool in troubleshooting an 
MPE-V system link. 



What is the LAN Node Diagnostic? 



Required Hardware 



The LAN Node Diagnostic, or LANDIAG, is an interactive online program 
designed to help identify malfunctioning LAN link hardware. The diagnostic 
performs a series of tests upon the LANIC card and interface hardware. Each 
test diagnoses a subset of the node's link hardware. Although it can help to 
identify a particular field replaceable unit (FRU), it may may not be able to 
distinguish which particular circuit within the FRU is malfunctioning. 

As a program running on the HP3000, LANDIAG tests the connection between 
the host computer and the main module of the LANIC card. The main module 
is that part of the LANIC card hardware which performs the network interface 
activities. 

LANDIAG can be used to initiate card self test. The LANIC self test checks the 
components on the card for operation in the IEEE 802.3 environment. For more 
information on LANIC card self test, see Chapter 5. 



LANDIAG is provided with the link products and HP network services 
(NS3000/V) software. When running this software, the system must have a 
minimum of two megabytes of memory and the Expanded System Table 
Microcode. (Systems that are now memory-limited should add one megabyte to 
maintain current performance.) 

When using LANDIAG, one of the following LAN link products should be 
installed: 

- ThinLAN3000/V or LAN3000/V links, for connecting HP 3000 Series 
3X/4X/5X/6X/7X and M1CRO3000 systems to a ThinLAN or ThickLAN 

coaxial cable, respectively. 

- StarLAN3000/V link, for connecting HP 3000 Series 37 or MICRO3000 
systems to an HP StarLAN twisted pair cable. 
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Required Software 



A maximum of one LAN hardware link per system is supported. 

For general LANIC card installation guidelines, and interdependencies with other 
I/O cards, refer to the LANIC installation manual provided with your particular 
link product. 



LANDIAG3000/V, version A.55.2 7.000, runs on HP 3000 or MICRO3000 systems 
executing the MPE V/E operating system, version U-B-delta-1 (or later). This 
version of LANDIAG incorporates changes required for the support of StarLAN 
connections. In addition, known bugs were corrected. 

The diagnostic is provided on a master installation tape (MIT). It is provided 
along with the LANIC card driver and NS3000/V. 

The diagnostic is intended to be an online program, running on the MPE-V 
operating system. It may be run timeshared with other programs, so that the 
LAN hardware may be inspected without disrupting the activities of users who 
do not need to access the network. 



NOTE 



Execution Time 



All network activity, including NS3000/V, must be halted before the diagnostic 
can be executed. 



System Tables 

LANDIAG is normally installed with NS3000/V and the driver. Before 
configuring and activating NS3000/V and the LAN link, you should check the 
system tables. Consult the "System Configuration" sections in the NS3000/V 
Network Manager Reference Manual, 32344-90002, for guidelines on system table 
modifications required. 



The diagnostic can execute one complete cycle of tests in under one minute. 
This is all the time needed to determine that the hardware is free from most 
defects. However, if there are intermittent or unusual problems, many passes 
through the diagnostic may be required. 
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Tests Included 



Table 4-1 lists the primary tests run from LANDIAG. These are described in 
detail later in this chapter. 



10 



11 



12 



13 



14 



15 



16 



17 



Table 4-1. LAN Node Diagnostic Tests 



Roll Call 



Channel ID 



Initialization 



Self Test 



Interrupts 



Soft Reset 



CR SR Loop 



Bus Conflict 



Address Offset 



Extended Address 



FIFO Write 



F/P Conflict 



Coprocessor 



MAU Loopback (also used for StarLAN loopback) 



Date Code 



Loopback Hood (Not Applicable for StarLAN Connections) 



Remote Node 
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Diagnostic Limitations 

The following conditions are not tested from LANDIAG: 



1. 



Selftest toggle switch failure (does not apply to Series 37 and MICRO3000 
LANIC cards). 



2. Light emitting diode failure. 

These are not tested by the diagnostic because they cannot be handled 
programmatically. It would be a simple matter to verify their operation by 
observation after initiating self test. 

3. Priority logic failure. 

The diagnostic cannot explicitly control or implicitly predict the state of the 
priority lines, so testing is not possible. However, failure recognition is 
possible. If the priority logic does not work, one of the following will likely 
result: 

- erratic LANIC card operation, 

- performance degradation, or 

- SIMB/IMB deadlock. 

4. Powerfail warning holdoff of master handshake. 

Testing this condition would require creating a powerfail condition in the 
host, which is beyond the scope of this diagnostic. 

5. SIMB/IMB parity errors. 

To test the parity error detector circuit, it would be necessary to risk system 
integrity by deliberately introducing parity errors into memory. 

The need to test the parity error detection circuit from LANDIAG was not 
felt to be necessary. Such faults are not catastrophic to system or network 
operation. In addition, other cards on the system would eventually detect a 
parity error. 

6. Faulty bank lines that address out of bounds memory. 

Though this condition will not be tested explicitly, it would be apparent if it 
occurred. For example, on the series 39, 4x or 6x systems, the 1MB would 
hang if out of bounds addressing occurred. 
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Holdoff of reset until handshake ends. 

For Series 39 through 70 systems, the LANIC is protected from data loss if 
the self test switch is inadvertently pushed during a handshake. This feature 
is not tested because it requires direct manual intervention. If the 
implementation circuitry were to fail and go undetected, the functionality 
of the LANIC card would not be significantly impaired. 
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Guidelines for Setting Up and Using LANDIAG 



System Information 



Capability Levels 



This section contains information that you will need to know before using 
LANDIAG. 



When the HP 3000 is configured, it needs to be told everything about the LANIC 
card, including its LDEV number, DRT number, driver name, device type and 
device subtype. The following information should be provided: 

- Driver name: lOLANO. PUB. SYS 

- Device type: 17 

- Device subtype: 9 

The LDEV number and the DRT number depend on the particular system 
configuration. Refer to the MPE V System Operation and Resource 
Management Reference Manual (32033-90005) for system configuration details. 

To use LANDIAG, you will need the LDEV number of your LANIC card. It is 
the first item requested by the diagnostic. The diagnostic locates the LANIC 
card by entering the I/O configuration table at the specified LDEV. If the table 
indicates that the LDEV is not device type 17 and subtype 9, the user is told: 

That LDEV is not configured as a LANIC. 



Because the diagnostic has direct access to every location in memory, use of the 
program is controlled. 

The user must have one of these three capabilities in order to run the diagnostic: 

OP - system supervisor or operator 
DI - diagnostician 
SM - system manager 

If the user's security level is not sufficient, the following error message will be 
displayed on the screen: 

OP, DI or SM capability needed to run diagnostic. 

For LANDIAG Test 17 (Remote Node Test), a CS capability - allowing access to 
the Communications Subsystem - is also required. 
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System Type Check 



For Series 30/33 systems, the diagnostic will continue to run, but the following 
warning is issued: 

Diagnostic not designed for HP3000 /30 or/33. 



Operation with Network Services 



Refer to the NS3000/V Network Manager Reference Manual (32344-90002) for 
software configuration of network services on the system. 

When a communication subsystem has control of the LANIC card, any attempt 
to allocate it by the diagnostic will fail. The diagnostic will report a warning. 
The message will be: 

The LANIC could not be allocated. 

To use the diagnostic, the LANIC card must be in an "AVAILABLE" state. You 
can tell if the card is "AVAILABLE" as follows: 

- From MPE, issue the SHOWDEV command. The LDEVs will be listed 
along with availability information. Locate the LDEV of the LANIC card; 
the status must indicate "AVAILABLE". 

- From MPE, issue the SHOWCOM command, specifying the LDEV of the 
LANIC card (see Chapter 2). The card is available if the LINE is 
DISCONNECTED or CLOSED. 

With the NS3000/V services installed, the command sequence: 

:NSCONTROL STOP 
:NETCONTROL STOP 

will disconnect the user's node from the network. For more information on the 
use of these commands, refer to the NS/3000 Network Manager Reference 
Manual (32344-90002). 

The user may run the diagnostic when the communication subsystems have 
released the LANIC card. The system can recover control of the LANIC if there 
should be a crash while the diagnostic is running. 
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Reliability and Recovery from Power Failure 



In the event of a power failure MPE-V/E will protect the integrity of the system 
tables. For the Series 6x/70 systems, the diagnostic process will resume operation; 
no reinitialization will be necessary. For the Series 4x/5x systems, you have to 
restart the diagnostic. 

The test which was underway when the power failure occurred will probably 
report a failure, whether or not the circuit being checked was actually faulty. 
This mistake will arise because the diagnostic will almost certainly timeout 
waiting for a response from the LANIC. This is because the LANIC (which 
derives its power from the backplane) will lose the execution context as its 
microprocessor and RAM will lose power due to power failure. Also, the 
LANIC performs a self test at power on, including a memory test which 
obliterates the contents of local RAM. 



When a power failure has taken place, you should redo any test that failed. 



Integrity of the System 



The diagnostic will expose any defect in the LANIC card which compromises 
system integrity. If the LANIC card contains such defects, there is an 
unavoidable risk of altering memory or system crashes. Because the diagnostic 
performs rigorous testing of all LANIC circuits, including those that implement 
direct memory access, intermittent problems will be exposed. 

The diagnostic will not cause any crashes or damage to system memory when 
good LANIC cards are tested. The diagnostic is no more likely to cause system 
problems than normal use of the LANIC by the LAN link and NS3000/V 
products. 

When a LANIC is installed or replaced, the diagnostic should be executed and 
system integrity verified before user processes are permitted to execute. If 
system failures are observed during normal operation and the LANIC is 
suspected to be the cause of the failures, users should be removed from the 
system prior to diagnostic execution. 

If a LANIC card malfunction is suspected, but LANIC usage does not appear to 
have compromised subsystem integrity, it is unlikely that diagnostic execution 
will cause system integrity to be compromised. In this case the diagnostic can be 
executed without removing the users from the system. 

Each time LANDIAG is run, it enforces conditional execution of its tests in 
order to significantly reduce the probability of system halts. Table 4-2 shows 
various test completion states and their impact on other tests. (Note that 
intermittent failures on the LANIC card may defeat the protection provided.) 
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Table 4-2. Test Dependencies 



Control Test (State) 



Roll Call (test 1) ran and found that the channel 
# corresponding to the specified LDEV did not 
respond. 



Channel ID (test 2) ran and found that 
responding channel at specified LDEV does not 
appear to be a LANIC. 



Network Service is still active as determined 
during the diagnostic initialization process. 



Address offset (test 9) ran and encountered a 
failure. This most likely indicates the LANIC is 
unable to address memory correctly while 
reading. 

Extended address (test 10) encountered a failure. 
This most likely indicates the LANIC is unable 
to address memory correctly while reading. 



Dependent Test (State) 



No other test is allowed to run because a 
non-responding channel will cause a a system 
halt for addressed 1MB instructions. 



Test 3 thru 1 7 are not allowed to run because 
certain LANIC instructions may cause a system 
halt if issued to other than a LANIC. 



All tests except Roll Call (test 1) and Channel 
ID (test 2) are prevented from executing since 
they will alter the state of the LANIC, thus 
disrupting Network Service. 



The FIFO write (test 11), F/P conflict (test 12) 
and Date Code (test 15) tests are not allowed to 
run because each of these tests write into system 
memory. If an addressing failure exists then the 
write may alter memory not allocated to the 
diagnostic. 
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Running LANDIAG 

To run LANDIAG, type the following at the MPE prompt: 

run landiag. pub.sys 

LANDIAG will ask you for the LDEV number of your LANIC card. If it is a 
valid LDEV, LANDIAG will be ready to use. LANDIAG uses the ">" character 
to prompt you for input. 

Figure 4-1 illustrates a typical user running LANDIAG. 



: run landiag 

LAN Node Diagnostic, version A. 55. 27. 000 HP1984 (c). 

Please enter Idev number of LANIC to be tested. 

36 

Enter 'H' for help. 

> 



Figure 4-1. Running LANDIAG 



Figure 4-2 is a high level state diagram for the use of LANDIAG. It 
demonstrates the path that a user will follow to execute the diagnostic. Further 
details will be provided later in this chapter. 
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MPE Entry State 

- NS3000A/ active 

- no line printer equate 



v 



:NSCONTROL STOP 
:NETCONTROL STOP 



MPE Entry State 
NSSOOOA^ nonactive 
no line printer file equate 



^ 



MPE Entry State 
NS3000/V nonactive 
line printer file equate establistied 



:RUN LANDIAG.PUB.SYS 



;FILE LP;DEV=LP 
:RUN I_ANDIAG,PU8.SYS 



± 



Program Initiation State 

- List file is initialized 

- Program emits title message 

- Prompts for LANIC LDEV and 
tests for valid device 



^ 



> 



/\ 



program 
\l/ ready 




:FCOPY FROM = DiAGLiST ; TO = *LP 
or :FCOPY FROM = DIAG# : TO = »LP 



>EXIT 



Program Input State { > ) 

Select Options 
default: Loop = l 
Printon 
Test = ALL 



>G0 
( resumes 
execution ) 



/\ 



\/ 



Control-Y 




> LOOP [ n I 

> NOPRINT. PRINT 

> TEST I n / ALL 1 
>HELP 



Program Execution State 

- Executes program per default or TEST options 

- Emits messages per PRINT option 



Tests done 



/\ 



«— NO 



LOOP ON ? - YES 



to first 

selected 

test 



Figure 4-2. Program Slate Diagram 
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User Interface 



Activity Indicator 



The diagnostic is an interactive program. The user determines the type of 
operation, performs a diagnosis, and is permitted to change the operating 
condition and test again, as many times as desired. The diagnostic is divided into 
three sections: 

- Initialization , in which setup takes place, transparently to the user, except 
for being asked LDEV number and getting initialization error messages if 
they occur. 

- Command entry , in which the user specifies the type of diagnostic 
operation. 

- Test execution , in which the hardware is inspected, faults are detected, and 
the results are output. 

After test execution is complete, or the user aborts test execution with a 
ICONTROLI Y. the program will return to the command entry mode. Subsequently, 
the user may change the type of operation and test again, or exit from 
LANDIAG to MPE. 

The LAN Node Diagnostic can be used in either of two ways. Active mode or 
Standard mode: 

- Standard mode: a predetermined sequence of tests is run; the user is not 
able to specify which tests to run. (Refer to the GO command, later in this 
chapter.) 

- Active mode: tests are user specified. (Refer to the TEST command, later in 
this chapter.) 



LANDIAG time requirements for test completion depend on the test(s) run. If 
tests are repeated (LOOP command), completion time is extended. To provide 
status of test progress, the diagnostic provides activity indicators. Before any test 
is begun, the number of the test is displayed on the screen. As each step within 
the test is begun, an asterisk (*) is displayed on the screen. 

If the system hangs, the user can determine which test and step was running just 
prior to the hang. This information may prove useful for identifying and 
correcting a problem. After the last step in a test is completed, the message 

end of pass 

is displayed. 



LAN Node Diagnostic 
4-12 



How to Get Output From LANDIAG 



While all prompts, echoes, activity indicators and other useful information will 
be sent to the user's screen, a summary of diagnostic results will be directed to 
both the screen and the file known as DIAGLIST, if the diagnostic was invoked 
with :RUN LANDIAG. 

The file can also be named DIAG# where j^=LDEV# if the diagnostic is invoked 
with: 

;RUN LANDIAG; parm=/.£)iEl/#. 

For example, if : RUN LANDIAG; pa rnri=36 is used, diagnostic results are directed 
toa file DIAG36. 

The user will not be able to use a file equation to associate the diagnostic output 
file with another file or device. In order to obtain hard copy of the diagnostic 
activity, the user should direct the diagnostic output to a printer after the process 
is complete. 

The command sequence is as follows: 

FILE LP;DEV=LP 

FCOPY FROM =DIAGLIST;TO=*LP , or 

FCOPY FROM =DIAG#;TO=^LP 



NOTE 



DIAGLIST (or DIAG#) is reinitialized every time LANDIAG is invoked, hence 
results from a previous diagnostic pass are lost. The user may save the results by 
either printing a hardcopy as shown above or renaming the previous diagnostic 
list file as follows: 

: RENAME DIAGLIST, filename , or 
: RENAME DIAG#, filename 

Where #=LDEV number of LANIC being tested. 
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station (Link-Level) Addresses 



Each node on the LAN is identified at the link level by a unique station address. 
The station address is a 12 digit hexadecimal number stored on the LANIC card 
in ROM. It is normally labeled on the card, and documented on the network 
map. (Do not confuse the station address with the IP address of the node. The 
IP address is an upper layer address for connecting processes.) 

For some tests, specifically the Remote Node Test, the station address of various 
nodes may be needed. For HP 3000 systems, the station address can be obtained 
through LANDIAG. However, you must be on the system to get the station 
address of the LANIC card Installed hi that system. 

If tests 1, 2, and 13 of LANDIAG have been successfully run, the station address 
will be displayed at the bottom of the screen resulting from the HELP command. 
The HELP command is described later in this chapter. 
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Command Set 



Seven commands are available to the user: EXIT, GO, HELP, LOOP, PRINT, 
NOPRINT and TEST. Single letter abbreviations will be accepted and both upper 
case and lower case letters will be understood. There is another input the user 
can give, the 1 CONTROL] Y. which returns control from test execution back to the 
command entry mode. 



NOTE 



During the execution of most LANDIAG tests, response to a ICONTROlI Y may be 
delayed until after execution of a test step. 

Due to programmatic protection, aborting a Remote Node Test (LANDIAG Test 
1 7) may require multiple [CONTROLJ Y entries (i.e., you may be required to enter 
[CONTROLl Y several times). The test will normally abort with [CONTROLI Y after it has 
received a loopback response frame, or after it has timed out waiting for a 
response frame. 



During the command entry phase of the program, the user may issue instructions 
to control the operation of the diagnostic. Whenever a ">" prompt is provided, a 
command is expected. If the command set is used incorrectly, a error message to 
help the user will be given. Refer to the "Error Messages" section at the end of 
this chapter. 

The diagnostic is designed with default settings for all parameters except the 
LDEV to be tested. In most cases, use of commands other than TEST, GO, and 
EXIT will be rarely needed. 

The tests are designed to be executed in sequence. Each time LANDIAG is run, 
test dependencies are enforced to ensure system integrity. See Table 4-3. 
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Table 4-3. Test Dependencies 



Test must be run and pass 


before this test(s) is allowed to execute. 


Roll Call (Test 1) 


ALL other tests 


Channel ID (Test 2) 


Tests 3 through 1 7 


Address offset (Test 9) 


FIFO write (Test 11) 
F/P conflict (Test 12) 
Date code (Test 15) 
Remote Node (Test 17) 


Extended address (Test 10) 


FIFO write (Test 11) 
F/P conflict (Test 12) 
Date code (Test 15) 
Remote Node (Test 17) 



In Table 4-3, the last two dependencies ensure that system memory "reads" work 
properly before system memory "writes" are allowed. 

The Hood Loopback test and Remote Node test must be individually specified 
with the TEST command. They are special tests used for identifying FRU's and 
network faults. They should only be run after all previous tests have executed 
successfully. The individual commands are explained in greater detail on the 
following pages. 
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Diagnostic Dialogue Example 

An example of running and using LANDIAG is provided below. 



NSCONTROL STOP 



NETCONTROL STOP 



RUN LANDIAG. PUB. SYS 



<< shuts down network services >> 
<< shuts down lower level NS >> 
<< invoke LAN Node Diagnostic >> 



LAN Node Diagnostic (version A. 55. 27. 000) HP1984 (c) 

Please enter LDEV number of LANIC to be tested. 

36 << LDEV may be found in I/O 

configuration table >> 
Type 'H' for HELP 



> TEST 9 



<< indicates only test 9 is to be run >> 
<< initiates last test entered >> 



> GO 
9 << test dependencies invoked >> 

Tests 1 & 2 must pass for this test to execute. 

> TEST 1 



> GO 

1 ^ End of Pass 

> TEST 2 

> GO 

2 ^ End of Pass 

> TEST 9 

> GO 

9 ^^^^^ End of Pass 



<< run test 1 only >> 

<< initiates last test entered >> 

<< test 1 completed successfully >> 

<< run test 2 only >> 

<< initiates last test entered >> 

<< test 2 completed successfully >> 

<< run test 9 only >> 

<< initiates last test entered >> 

<< test 9 completed successfully >> 



(Continued on the next page) 
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> TEST 5 << run test 5 only >> 

> LOOP 3 << sets the test loop parameter to 3 >> 

> GO << initiates last test entered >> 

5 ^^^^^ End of Pass << test 5 pass 1 completed successfully >> 

5 ^^^^ << test 5 pass 2 detected an error >> 

Error in test 5, step 4 (Interrupt Test) MON, APR 6, 1987, 10:17 AM 
End of Pass 

5 ^^^^ End of Pass << test 5 pass 3 completed successfully >> 

> run << user input an invalid command >> 
Bad input - Try again or enter "Help". 

> GO << initiates last test entered >> 

5 ^^^^ End of Pass << test 5 pass 1 completed successfully >> 

5 4^4^^^ End of Pass << test 5 pass 2 completed successfully >> 

5 ^^^^ End of Pass << test 5 pass 3 completed successfully >> 

> EXIT << stop execution of LAN Node Diagnostic >> 
End of LAN Node Diagnostic. 
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Command Entry Abbreviations 



Fault Messages 



Command entries may be abbreviated. The first character of the command is 
normally sufficient, followed by the appropriate parameters. For example, the 
following command entries are equivalent: 

HELP = H 

LOOP = L 

LOOP 5 = LOOPS = L 5 = L5 

TEST 1 = TEST1 = T 1 = T1 

GO = G 



If a fault is detected during a test, an error message is returned to both the user's 
terminal and the output file. This message takes the following form: 

Error in test <testnum>, step <stepnum> (<testname> ) 
Where, 

<testnum> - Identifies the number of the test that was 
running when the fault was detected. 

<stepnum> - The number of the step in the test where the 
fault was detected. 

< test name > - Identifies the name of the test that was running 
when the fault was detected. 

The message will also contain the date and time. 
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HELP Command 

HELP provides a list of commands and tests. The HELP screen is shown here: 

Node Diagnostic Commands and Tests 

EXIT terminates this program and returns to MPE. 

GO initiates execution of the test set. 

HELP displays this screen. 

LOOP [N] chooses the number of times the test set is executed. 

(Default = 1) 
NOPRINT suppresses terminal and file output. 
PRINT resumes generation of output. (Default) 
TEST < n / ALL > selects a single test or tests 1-15. 

(Default = ALL) 

type < control - y > to discontinue testing. 

#1 Roll Call Test #7 OR SR Loop Test #13 LAN Coprocessor Test 

#2 Channel ID Test #8 Bus Conflict Test #14 MAU Loopback Test 

#3 Initialization Test #9 Address Offset Test #15 Date Code Test 

#4 Self Test #10 Extended Address Test #16 Hood Loopback Test 

#5 Interrupt Test #11 Fifo Write Test #17 Remote Node Test 

#6 Soft Reset Test #12 F/P Conflict Test 

Local station address is given in help menu after test 13 is run. 



In a given LANDIAG session, the HELP command can be used to identify the 
local station (link-level) address stored on the LANIC card, but only after Test 
#13 is run. The local station address will be displayed at the bottom of the HELP 
screen as follows: 

Local station address is nnnn nnnn nnnn nnnn 

where a? is a hexadecimal digit. 
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EXIT Command 



30 Command 



LOOP Command 



EXIT terminates the diagnostic and returns to MPE. 

Execution of the EXIT command is the only wa y to retu rn control to MPE. 
When the user stops the test execution with the [CONTROLJ Y character, the 
diagnostic will not terminate. It merely returns to the command mode. 



GO begins or continues execution of tests. The tests that are performed when the 
GO command is entered are determined by the test selected with the latest 
TEST<n/all> command. The number of times the test is looped is set by the 
LOOP command. If neither command was given, GO will cause the initiation of 
one pass of the complete test set (Test 1-15). 

Once testing has begun, testing may be stopped before completion of the selected 
test (with the specified number of loops) by entering a ICONTRQLJY character. This 
will return the user to the command entry mode, identified by the > prompt. 
After a IcontrolI Y. a subsequent GO command will simply restart the same test. 



The LOOP command establishes the number of times that a test, specified by the 
TEST command, is continuously run. Using this command, a test may be run a 
number of times without repeated command entry. 

If LOOP is not specified during a LANDIAG session, its value defaults to "1". The 
number of times a test is repeated is determined by the parameter A^ following 
the LOOP command. This is illustrated as follows: 



> LOOP 5 

> LOOP 1 

> LOOP 



N = 5, the test will be run 5 times. 

N = 1, the test will be run once. 

N = 0, the test will be run continuously. 



The LOOP command is used primarily to find intermittent problems, or to study 
the link hardware with an oscilloscope. It is recommended that oscilloscope 
loops be performed with "print off" (see the NOPRINT command). 

Once testing has begun, the only way to terminate execution before A^ iterations 
of the test is with [coNTROLJ Y. This will return the user to the command entry 
mode, identified by the ">" prompt. 
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NOPRINT Command 



PRINT Command 



NOPRINT suppresses terminal and file output. It is useful during loop tests with 
an oscilloscope since it eliminates overhead associated with such output and 
increases the speed by which an iteration is made. 



PRINT resumes generation of terminal and file output, which is the default state. 
The filename being logged to depends on the way in which you invoked the 
diagnostic. 

If PARM is used in the LANDIAG run string to specify the card's LDEV, then the 
log file name is DIAG#, where #=FARM=LDEV. This is illustrated below: 

:RUN LANDIAG. PUB. SYS; ?km=LDEV 

If PARM is not used, then the log file is DIAGLIST. 

Note that DIAG# or DIAGLIST will be in the group.account from which you 
invoked LANDIAG. 



TEST N/ALL Command 



The TEST command is used to select the LANDIAG test to be run. The desired 
test is specified by a parameter, N, in the command run string. Note the 
following: 

N = default (see "N = ALL", below) 
N = default (see "N = ALL", below) 
N = 1, Test 1 is run. 
N = 2, Test 2 is run. 



TEST 




TEST 





TEST 


1 


TEST 


2 


TEST 


15 


TEST 


ALL 


TEST 


16 


TEST 


17 



N= 15, Test 15 is run. 
N = ALL, Tests 1 through 15 are run. 
N = 16, Test 16 is run (coax LANs only). 
N= 17, Test 17 is run. 

There are a couple of noteworthy points: 

• If A' is "0" or not specified, the default is A LL. 

• Tests 16 or 17 can be executed only with the commands TEST 16 or 
TEST 1 7, respectively, followed by the GO command. 
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Test Descriptions 



LANDIAG provides a number of Tes/s, each consisting of multiple Steps. 

A Test is a sequence of interactions between the host system and and the LANIC 
card designed to verify the correctness of data and control paths. 

A Step is a single interaction between the host and the LANIC intended to gather 
some information about a particular data or control path, contributing to the 
evaluation of that path. 

Each test will begin with a reset of the LANIC card, to bring it into a known 
state. In some of the tests, the next step will be to download a small piece of 
Z80 software. This code will prepare the LANIC card to perform subsequent 
steps. 

This section describes each LANDIAG test. 
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Test #1. Roll Call Test 
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The roll call test verifies that the channel specified by the user, via the LDEV, 
responds to the IMB\S1MB roll call instruction. The diagnostic requires the user 
to run this test prior to other tests since a nonresponding channel will cause a 
system halt. If this test fails, all subsequent tests are not allowed to run. 

Possible causes of failure include: 

- The system I/O table does not match the hardware configuration. 

- The I/O configuration table has been corrupted. 

- The LANIC card is faulty. 

If Test #1 fails, you should acquire a listing of the system I/O configuration (may 
use SYSDUMP $NULL ,$STDLIST) and verify that the mapping of LDEVs, 
DRT#s, and thumbwheel settings of all I/O channels are consistent. For help, 
refer to HP 3000 Computer Systems, MPE V System Operation and Resource 
Management Reference Manual (32033-90005). 

Correct any discrepancies found between the hardware channel settings and the 
system I/O configuration table. If there are no discrepancies, try replacing the 
LANIC card. 



NOTE 



The success of this test does not prove that there is a LANIC card at the correct 
channel number, only that there is a channel present. The next test verifies that 
the channel is a LANIC card. 



Test #2. Channel ID Test 



Test #2 verifies that the channel specified by the user, via the LDEV, is indeed a 
LANIC card. First, a check is made on the results of the Roll Call test (Test #1). 
If a responding channel is not present at the specified LDEV, Test #2 is not 
allowed to run. Next, register 14 (configuration register) of the specified channel 
is read and compared to a special ID code assigned to the LANIC card. If the 
channel responds with the correct ID code, the test passes. 

If Test #2 test fails, a flag is set that prevents all subsequent tests from running. 
This prevents the possibility of system halts. 

Possible causes of test failure include: 

- The channel specified by the LDEV is not a LANIC card. This assumes 
that the system has been configured correctly. 

- There are non-LANIC card channels with the same channel number as the 
LANIC card being tested (i.e., thumbwheel switches set to the same 
number). 

- The system I/O table does not match the hardware configuration. 

- The I/O configuration table has been corrupted. 

- The LANIC card is faulty. 

If Test #2 fails, you should acquire a listing of the system I/O configuration (may 
use iSYSDUMP $null,$stdlist). Verify that the mapping of LDEVs and 
DRT#s and thumbwheel settings of all I/O channels are correct. 

If there are discrepancies between the hardware channel settings and the system 
I/O configuration table, correct them. If there are no discrepancies, try replacing 
the LANIC card. 
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Test #3. Initialization Test 



Test #3 determines if the LANIC responds to the IMB/SIMB INIT instruction by 
halting the Z80 and clearing the CRFULL bit (an indication that an internal reset 
pulse is generated). There are 3 steps to this test: 

Step 1: The Z80 is launched into a self test to ensure that it is not initially in a 
halted state. A write to the control register is then performed to set 
the CRFULL bit. Subsequently, the CRFULL bit is checked; if it is not 
set, Step 1 fails. 

A Step 1 failure most likely indicates a LANIC failure. Replace the 
LANIC. 

Step 2: An INIT is issued to the LANIC card. This should halt the Z80 and 

clear the CRFULL bit. Subsequently, the CRFULL bit is checked; if it 
is not cleared, Step 2 fails. 

A failure in Step 2 most likely indicates a LANIC card failure. Replace 
the LANIC. 

Step 3: This step verifies that the Z80 was actually halted by the INIT in Step 
2. Another write to the Control register is performed to set the 
CRFULL bit. The diagnostic then pauses for 5 seconds; if the Z80 was 
not halted by Step 2, the CRFULL bit will be cleared. Subsequently, 
the CRFULL bit is checked; if it has been cleared. Step 3 fails. 

A failure in step 3 most likely indicates a LANIC card fault. Replace 
the LANIC card. 
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Test #4. Self Test 



Test #4 programmatically initiates the LANIC card selftest program contained in 
ROM on the card. The self test is a comprehensive verification of the LANIC 
main module, that is, all circuitry not associated with the IMB/SIMB interface. 
Refer to Chapter 5 for selftest LEDs and failure codes. 

There are three steps to this test: 

Step 1: This step issues an INIT to the LANIC card, then writes to the control 
register the code indicating that a full self test is to be run. Then it 
reads the status of the CRFULL bit, which should be set to 
acknowledge the control register write. If the CRFULL bit is not set, 
this step fails. 

A Step 1 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 

Step 2: This step consists of the following sequence. 

a. A write to the selftest control register is made. This starts the Z80 
and clears the interrupt mask. 

b. The interrupt mask is set. 

c. The diagnostic waits up to 10 seconds for a system interrupt 0, 
which indicates selftest completion. 

d. The selftest result register is read. The least significant bit (LSB) of 
this register is set only while the self test is running. 

If the system interrupt is not detected, Step 2 fails. 

A Step 2 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 

Step 3: If the LSB of the selftest register is cleared, then self test has 

completed. The contents of the selftest result register are checked to 
see if self test completed without detecting a failure. If a failure was 
detected, Step 3 fails and the result is reported on the screen. 

A Step 3 failure does not necessarily mean a LANIC card fault. 
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If a selftest error is detected, it is displayed as an encoded decimal number and 
referred to as a "step number". For example, in Figure 4-3, "step number 46" 
implies the decimal error code is 46. 



> TEST 4 










> GO 










4 ^ii¥r 










Error in test 4, step 3 (Self Test) 


MON, 


APR 6, 


1987, 


11:00 AM 


Self test step number is 46 










End of Pass 
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Figure 4-3. Selftest Error Message Example 



For a coaxial cable connection, selftest steps number 36 (MAU power failure) or 
number 46 (external loopback failure) may result from a fault external to the 
LANIC card. To isolate such faults, refer to Test 16 (Hood Loopback Test). 

For a StarLAN connection, MAUs are not used. Therefore, a step number 36 
code should not be returned unless there is a card fault. If error code 36 occurs, 
replace the LANIC card. 



NOTE 



For selftest step number 46 to pass, the LANIC card must be properly connected 
to the network, or to an appropriate loopback hood. Before detailed 
troubleshooting, you should check the cables and their connections. 



If any other selftest error codes (i.e., step numbers) are returned, replace the 
LANIC card. 



Test #5. Interrupt Test 



Test #5 verifies that tlie LANIC system interrupt mask is functioning properly 
and that the LANIC can issue a system interrupt 1. Note that system interrupt 
was checked in test 4. These are the only two system interrupts that the LANIC 
card can issue. 

This test is comprised of 4 steps: 

Step 1: The diagnostic issues an IMB/SIMB INIT instruction to place the 

LANIC card into a known state. It then writes the skip selftest code to 
the control register and starts the Z80 by writing to the selftest control 
register. This should put the LANIC in the kernel state. Finally, the 
diagnostic reads the OBII register. If the device number field of the . 
OBII register is not equal to 1 then Step 1 fails. 

A Step 1 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 

Step 2: The diagnostic then checks the IRQ bit of the OBII register. Since the 
LANIC interrupt mask is cleared, the IRQ bit should be unasserted. If 
the IRQ bit is asserted then Step 2 fails, otherwise it passes. 

A Step 2 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 

Step 3: The diagnostic issues a NOP kernel command to the LANIC card 

which should cause it to respond with a system interrupt 1. However, 
since the LANIC interrupt mask is still not set, the interrupt should be 
internally pending. The diagnostic reads the OBII register and verifies 
that the IRQ bit is still unasserted. If the IRQ bit is asserted. Step 3 
fails. 

A Step 3 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 

Step 4: The diagnostic does the following: 

a. Checks whether any interrupts have been detected since the test 
began, 

b. sets the LANIC interrupt mask, and then 

c. checks to see if the pending interrupt from step 3 is detected. 

If either an interrupt was detected before the mask was set, or no 
interrupt is detected after the mask is set. Step 4 fails. 

A Step 4 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 



LAN Node Diagnostic 
4-29 



Test #6. Soft Reset Test 



Test #6 verifies that a host write to the soft reset register does indeed cause a 
soft reset in the LANIC card. There are 3 steps to this test- 
Step 1: The diagnostic performs the following: 

a. Issues an INIT to the LANIC card, 

b. Writes to the control register the code indicating that a full self 
test is to be run, 

c. Checks the status of the CRFULL bit, which should be set, 
acknowledging the control register write. 

If the CRFULL bit is not set, Step 1 fails. 

A Step 1 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 

Step 2: The diagnostic performs the following: 

a. Writes to the selftest control register. This causes a hard reset 
which starts the Z80. 

b. Sets the interrupt mask which was cleared by the hard reset. 

c. Reads the selftest register and verifies that bit is set, indicating 
the self test is running. 

If bit of the selftest register is not set, Step 2 fails. 

A Step 2 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 

Step 3: The diagnostic performs the following: 

a. Writes OIH to the soft reset register. This should cause a soft reset, 
which aborts the self test and starts the KERNEL firmware. 

b. Writes a NOP to the control register, which causes the KERNEL to 
respond with a system interrupt 1. 

If a system interrupt 1 is not detected. Step 3 fails. 

A Step 3 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 
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Test #7. CR-SR Loop Test 



This test verifies that writes to the LANIC card control register (CR), and reads 
from the status register (SR), are processed correctly by the LANIC card. 

The LANIC CR-SR kernel command is used for this test. This command causes 
the last word read from the control register to be written back out to the status 
register. 

There are 6 steps to this test: 

Step 1: Reset the LANIC card and issue the CR-SR loop kernel command with 
the test pattern = AAAAH. If an error is detected while issuing the 
kernel command, Step 1 fails. 

A Step 1 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 

Step 2: After the kernel command completes, a system interrupt 1 should be 
issued indicating to the host that the command has completed. If a 
system interrupt 1 is not detected then Step 2 fails. 

A Step 2 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 

Step 3: The diagnostic then reads the status register. This register should 

contain the alternating I's and O's test pattern (AAAAH) written to the 
control register in Step 1. If the status register does not contain 
AAAAH step 3 fails. 

A Step 3 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 

Step 4: The diagnostic again issues the CR-SR loopback kernel command, this 
time with 5555H as the test pattern. If an error is detected while 
issuing the command, Step 4 fails. 

A Step 4 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 
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Step 5: After the kernel command completes, a system interrupt 1 should be 
issued indicating to the host that the command has completed. If a 
system interrupt 1 is not detected, Step 5 fails. 

A Step 5 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 

Step 6: The diagnostic reads the status register. It should contain the test 
pattern 5555H, the last word written to the control register in the 
CR-SR kernel command. If the status register does not contain 5555H, 
Step 6 fails. 

A Step 6 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 
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Test #8. Bus Conflict Test 



Test #8 verifies that simultaneous requests made on the LANIC card backplane 
interface from both the LANIC card main module and the IMB/SIMB are 
properly arbitrated. The interlock kernel command is used to invoke write 
alternating AAAAH and 5555H test patterns to the status register. Concurrently, 
the host is reading the status register. If there is an arbitration error, one or more 
status register reads by the host will be other than the test patterns described 
above. 

There are 2 steps to this test: 

Step 1: The LANIC is first reset, which should place it in the kernel state, 

ready to accept commands from the host. The interlock command is 
then issued and the return code checked. If an error was detected 
while issuing the kernel command. Step 1 fails. 

A Step 1 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 

Step 2: The diagnostic reads the status register 500 times with interrupts 
disabled. The interrupts are disabled to ensure that the 500 status 
register reads take place while the LANIC is executing the interlock 
kernel command. The diagnostic then verifies that each of the status 
register reads was either AAAAH or 5555H. If an invalid test pattern 
is detected. Step 2 fails. 

A Step 2 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 
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Test #9. Address Offset Test 



Test #9 verifies the operation of tlie LANIC card IMB/SIMB address drivers. 
The download Icernel command is an integral part of the test. It is used to 
download a block of words from host memory. The success of the transaction is 
checked by comparing its computed checksum to that computed by the 
diagnostic. Note that 'Data Bus' failures can also cause a bad checksum; 
however, these failures should be exposed by Test #4 (Self Test) or Test #7 
(CR-SR Loopback), depending on the location of the fault. 

There are 5 steps to this test: 

Step 1: The diagnostic first places the LANIC in the kernel state, ready to 
accept interactive commands from the host. It then enables the 
LANIC master handshake circuitry, thus allowing the LANIC to read 
form host memory. This step fails if either the LANIC card was not 
successfully placed in the kernel state, or the master handshake could 
not be enabled. 

A Step 1 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 

Step 2: A block of words from bank 1 in host memory is read and a checksum 
computed by the diagnostic. The LANIC card is then instructed to 
read the same block of words via the download kernel command. 
Finally, the diagnostic once again reads the same block of words from 
host memory. If the first and second read by the diagnostic are not the 
same, the sequence of three host memory reads ~ by the diagnostic and 
LANIC card -- is repeated. This is done up to 3 additional times, after 
which the diagnostic aborts Step 2 and reports a failure. 

A failure of Step 2 does NOT indicate a LANIC card fault. It 
indicates that the diagnostic was unable to use the predefined test 
block for this test - either it changed too often or a memory failure 
exists. Try to rerun this test when the system is under less load. 

Step 3: After it issued the download kernel command in Step 2, the diagnostic: 

- waited for a system interrupt 1 from the LANIC card indicating 
that the download had completed, and 

- read the status register which contained the completion code from 
the kernel indicating whether the checksums matched. 

If either a system interrupt 1 was not detected, or the completion code 
did not indicate a successful download. Step 3 fails. 

The successful completion of Step 2 and a failure in Step 3 most likely 
indicates a LANIC card fault. Replace the LANIC card. 
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Step 4: The diagnostic reads a block of words in bank 1 of memory, however, 
the bank offset is chosen so that the address lines are the complement 
of those used in Step 2. The diagnostic then instructs the LANIC card 
to read the same block of words and compare the the checksum to 
that computed by the diagnostic. The diagnostic reads the test block 
again and compares it to the first read. If the first and second read do 
not match, the sequence of three host memory reads between the 
diagnostic and LANIC is repeated. This is done up to 3 additional 
times, after which the diagnostic aborts Step 4 and reports a failure. 

A failure in Step 4 does NOT indicate a failure of the LANIC. It 
indicates that the diagnostic was unable to use the predefined test 
block for this test because either it changed too often, or a memory 
failure exists. Try to rerun this test when the system is under less load. 

Step 5: After it issued the download kernel command in Step 4, the diagnostic: 

- waited for a system interrupt 1 from the LANIC card indicating 
that it had completed the download, and 

- read the status register which contained the completion code from 
the kernel indicating whether the checksums matched. 

If either a system interrupt 1 was not detected, or the completion code 
did not indicate a successful download, Step 5 fails. 

If Step 4 completes successfully while Step 5 fails, a LANIC card fault 
is likely. Replace the LANIC card. 
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Test #10. Extended Address Test 



Test #10 verifies the operation of the LANIC card extended address bus drivers. 
Like the Address Offset test (Test #9), the diagnostic uses the download kernel 
command to download a block of words from host memory, and checks the 
success of the transaction. The diagnostic starts with bank 1 and proceeds bank 
by bank until the next bank to be tested exceeds the maximum bank of 
configured memory. 

Note that this test depends on the amount of memory configured in the host. 
Only those extended address bits required to access this memory are tested. 

Also, note that failures of the 'Data Bus' or 'Lower (Offset) Address Bus' on the 
LANIC card could cause this test to fail. However, such failures should be 
exposed in previous tests (e.g., Self Test, CR-SR Loopback and/or Address Offset 
tests). 

Step 1: The diagnostic performs the following: 

- prepares the LANIC card for this test by placing it in the kernel 
state, and 

- enables its master handshake. 

If the diagnostic detects an error either while placing the LANIC card 
in the kernel state, or attempting to enable master handshake. Step 1 
fails. 

A Step 1 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 

The following steps are systematically repeated (i.e., first Step X, then Step Y) for 
each memory bank tested: 

Step X: The diagnostic reads a block of words from bank N (where N = 1, 2, 4, 
8, ..., until the next bank to be tested exceeds the maximum bank of 
configured memory) in host memory and computes the checksum. The 
LANIC card is then instructed to read the same block of words via the 
download kernel command. Finally, the diagnostic again reads the 
same block of words. If the first and second reads by the diagnostic 
are not the same, the entire sequence is repeated. This is done up to 3 
additional times, after which the diagnostic aborts the test on this bank 
and reports a failure in this step. 

A failure in Step "X" does NOT indicate a failure of the LANIC It 
indicates that the diagnostic was unable to use a specific bank of host 
memory for this test because either it changed too often, or a memory 
failure exists. Try to rerun this test when the system is under less load. 
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Step Y: After it issued the download kernel command in the previous step 
(Step X), the diagnostic: 

- waited for a system interrupt 1 from the LANIC card indicating 
that the transaction completed, and 

- read the status register that contained the completion code from 
the kernel indicating whether the checksums matched. 

If either a system interrupt 1 was not detected, or the completion code 
did not indicate a successful download, this step fails. 

A failure in Step Y (presuming Step X passed) most likely indicates a 
LANIC card fault. Replace the LANIC card. 
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Test #11. FIFO Write Test 



Test #1 1 exercises the LANIC card master handshake logic not tested by the 
Address Offset test (Test #9). Firmware is downloaded to the LANIC card that 
will write a predefined test frame into the extra data segment allocated to the 
diagnostic. The diagnostic then compares its copy of the test frame to that 
written by the LANIC card. An error is reported if the frames are not the same. 

The test includes 5 steps: 

Step 1: The LANIC card is reset and the master handshake is enabled, thereby 
preparing it for the download process. If either the reset or handshake 
enable were not successful then Step I fails. 

A Step 1 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 

Step 2: The diagnostic moves the firmware to the LANIC card via the 

download kernel command. Then, it waits for a system interrupt 1 
that indicates the download has completed. 

After the interrupt is detected, or a time out occurs, the diagnostic 
reads the download completion code from the status register. If either 
the interrupt is not detected, or an unsuccessful completion code is 
encountered, Step 2 fails. 

A failure of Step 2 most likely indicates a LANIC card fault. Replace 
the LANIC card. 

If a failure was detected while attempting to download the firmware, 
the diagnostic will not continue the test, that is, Steps 3 thru 5 are not 
performed. 

Step 3: If the download was successful, the LANIC is instructed to start 
execution of the code. The diagnostic then waits for a system 
interrupt 1 that indicates firmware code completion. If the interrupt is 
not detected within the time allotted. Step 3 fails. 

A failure of Step 3 most likely indicates a LANIC card fault. Replace 
the LANIC card. 
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Step 4: Before issuing the system interrupt 1, tiie firmware writes a completion 
code into the status register. The diagnostic then reads the completion 
code from the status register. 

If the completion code does not indicate the test completed without 
error, Step 4 fails. 

A failure of Step 4 most likely indicates a LANIC card fault. Replace 
the LANIC card. 

Step 5: In this step, the diagnostic compares its copy of the downloaded test 
frame with that returned by the LANIC card. If the frames do not 
match, Step 5 fails. 

A failure of Step 5 most likely indicates a LANIC card fault. Replace 
the LANIC card. 
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Test #12. F/P Conflict Test 



Test #12 verifies that the LANIC card is able to properly arbitrate master 
handshake requests between its "first-in-first-out" (FIFO) buffers and processor. 

The following sequence is performed: 

- The FIFOs are loaded with 16 words of a test frame and are held off from 
writing to system memory until instructed by the host. 

- After the FIFOs are full, the Z80 processor notifies the host that the 
LANIC is ready to start the test. 

- Upon receiving the acknowledgment, the Z80 will simultaneously enable 
the FIFO writes to system memory and write its own test frames to 
another section of system memory. 

- The diagnostic will pause to allow the processor and FIFOs time to 
complete their writes to host memory. 

- The Z80 processor checks the FIFO out/in status before its first and second 
write to host memory and after its last write. 

- The Z80 processor then reports the results in the status register. 

There are 5 steps to this test: 

Step 1: The LANIC card is reset and its master handshakes enabled in 

preparation for the download process. If an error was detected during 
this initialization Step 1 fails. 

A Step 1 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 

Step 2: In this step, the following occurs: 

- The diagnostic erases any previous data from the extra data 
segment to prevent interpretation of erroneous data. 

- The diagnostic downloads firmware to the LANIC card, then waits 
for a system interrupt 1 (download completion) or a time out. 

- After the interrupt or time out, the diagnostic reads the status 
register. The register should contain the completion code of the 
download process. 
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If either the interrupt was not detected, or the completion code 
indicates an unsuccessful transaction, Step 2 fails. 

A failure in Step 2 most likely indicates a LANIC card fault. Replace 
the LANIC card. 

The following steps are executed only if Step 2 passes: 

Step 3: In this step, the following occurs: 

- The diagnostic issues the start code kernel command to start 
execution of the downloaded firmware. 

- The diagnostic waits for a system interrupt 1, indicating the 
firmware has finished setting up the test. 

- The status register is read for the appropriate initialization 
completion code provided by the firmware. 

If the interrupt is not detected after a predefined interval, or the 
completion code indicates the LANIC did not set up correctly, Step 3 
fails. 

A failure of Step 3 most likely indicates a LANIC card fault. 
Replace the LANIC card. 

Step 4: If a system interrupt 1 is correctly received in Step 3, the diagnostic 
writes the GO command to the control register. This causes the FIFO 
and Z80 processor to write to host memory in a round robin fashion. 
Subsequently, the diagnostic waits for a system interrupt I, indicating 
the LANIC card has completed the test. 

After an interrupt or time out, the diagnostic reads the completion 
code in the status register. If either the interrupt was not detected, or 
the completion code does not indicate successful completion of the 
firmware. Step 4 fails. 

A Step 4 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 

Step 5: Finally, the diagnostic moves the test frames (written by the FIFOs and 
Z80 processor) from the extra data segment to the stack, and checks 
their contents. If they contain errors. Step 5 fails. 

A Step 5 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 
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Test #13. Coprocessor Test 



Test #13 verifies that the LAN coprocessor (INTEL 82586) can detect/report a 
CRC error and correctly process multicast frames received by it. 

There are 5 steps to this test: 

Step 1: In this step, the following occurs: 

- The diagnostic resets the LANIC card and downloads firmware. 

- The diagnostic waits for a system interrupt 1, indicating the 
download has completed, or a time out. 

- After the interrupt or timing out, the diagnostic reads the status 
register for the proper completion code of the download process. 

If the interrupt was not detected, or the completion code indicates an 
unsuccessful transaction. Step 1 fails. 

A Step 1 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 

Step 2: If the download was successful, 

- the diagnostic initiates the downloaded code and waits for a system 
interrupt 1 from the LANIC card. 

- It reads the status register and checks for the proper status code 
that indicates the firmware is ready to continue testing. 

If a system interrupt 1 is not detected, or the code in the status register 
indicates an error. Step 2 fails. 

A failure in Step 2 most likely indicates a LANIC card fault. Replace 
the LANIC card. 
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The following steps are executed only if Steps 1 and 2 pass. 
Step 3: Coprocessor Initialization. In this step, the following occurs: 

- The diagnostic instructs the firmware to continue the test. 

- The diagnostic waits for another system interrupt 1, which 
indicates that the firmware has completed the test and has placed 
the first result in the status register. 

- On detecting the interrupt, or if a time out occurs, the diagnostic 
reads the first test result from the status register. 

If the interrupt is not detected, or the first result reported (Coprocessor 
initialization step) has failed, Step 3 fails. 

A failure in Step 3 most likely indicates a LANIC card fault. Replace 
the LANIC card. 

Step 4: Multicast Test. As the firmware test code continues, the diagnostic 

reads the status register again, which should now contain the results of 
the multicast test. If test results indicate a failure, then Step 4 fails. 

A failure in Step 4 most likely indicates a LANIC card fault. Replace 
the LANIC card. 

Step 5: CRC Test. As the firmware test code continues, the diagnostic reads 
the status register again, which should now contain the result of the 
CRC test. If test results indicate a failure. Step 5 fails. 

A failure in Step 5 most likely indicates a LANIC card fault. Replace 
the LANIC card. 
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Test #14. MAU Loopback Test 



Test #14 verifies operation of the connection to the LAN. For coaxial cable 
connections, this includes the LANIC card, AUI cabling, and MAU/Tap or 
ThinMAU/BNC-Tee, as appropriate. For HP StarLAN connections, this includes 
the LANIC card and twisted-pair cable. 



NOTE 



Despite its name. Test #14 is used for testing connections to an HP StarLAN as 
well as a coaxial cable LAN. 

For Test #14 to pass, the LANIC cards must be properly connected to a 
functional coaxial cable or StarLAN Hub, or to appropriate loopback hoods. 



External loopback test firmware is downloaded to the LANIC card. This code 
will sequentially transmit and receive (i.e., loopback) 8 test frames to and from 
the LAN medium. Results are reported to the diagnostic in the status register. 
This includes: 

1. Whether MAU/ThinMAU power could be turned on (for the StarLAN 
card, the power line is tested even though there is no MAU/ThinMAU 
attached). 

2. The number of attempts required to turn the MAU/ThinMAU power on 
(tested for StarLAN cards even though there is no MAU/ThinMAU 
attached). 

3. The number of frames successfully looped back. 

4. The number of heartbeats detected from the MAU/ThinMAU (not tested 
on StarLAN cards). 

5. The number of collisions detected. 

6. The number of times a transmit was aborted due to excessive collisions. 

7. Whether the MAU/ThinMAU jabbed too soon (not tested for StarLAN 
cards). 

8. Whether the MAU did not jab at all (not tested for StarLAN cards). 
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9. Whether the LANIC could reset the MAU from a jabber condition (not 
tested for StarLAN cards). 

10. Whether the SQE disable function on the LANIC is operational (not tested 
for StarLAN cards). 

There are 9 steps to this test: 

Step 1: The diagnostic resets the LANIC card and downloads the external 
loopback test firmware. Subsequently, the diagnostic waits for a 
system interrupt 1 indicating the download has completed. A read of 
the status register is made - it should contain the download completion 
code. 

If the interrupt is not detected within a predefined time interval, or the 
completion code indicates an unsuccessful transaction, Step 1 fails. 



A Step 1 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 

Step 2: If the download completed successfully, the diagnostic initiates 

execution of the downloaded firmware. The diagnostic waits for a 
system interrupt 1, indicating the LANIC card has completed 
initialization and is ready to execute the tests. After receiving the 
interrupt, or if a time out occurs, the diagnostic reads the status register 
for a ready code returned by the firmware. 

If the system interrupt 1 was not detected, or the status register does 
not contain the appropriate ready code. Step 2 fails. 

A Step 2 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 
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The following steps are executed only if Steps 1 and 2 passed. 

Step 3: MAU/ThinMAU power line tests. If the download and start code 

(Steps 1 and 2) were correctly returned, the LANIC card is instructed 
to turn the MAU power supply line on. The diagnostic then waits for 
a system interrupt 1, indicating completion of this task. Subsequently, 
the diagnostic reads the status register for results returned by the 
firmware. 

The results indicate the status of two internal signals, MAUPWR and 
V12SENSE, specifically, whether or not MAU/ThinMAU power is on 
and how many attempts were required to turn the power on. 

If the task completion interrupt was not detected, or either of the 
internal signals indicate lack of MAU/ThinMAU power, Step 3 fails. 

For coaxial cable LAN connections, a Step 3 failure can result from a 
LANIC card, AUI cable, or MAU/ThinMAU fault. Refer to Test #16 
(Hood Loopback Test) to find the faulty unit(s). 

For StarLAN connections, the LANIC card most likely contains a fault 
and should be replaced. Test #16 does not operate for StarLAN 
connections. 

Step 4: External loopback tests. The diagnostic instructs the LANIC card to 
loop 8 test frames to the LAN and back. The firmware transmits and 
receives the test frames. 

During these loopback tests, the firmware monitors the number of 
collisions, aborts due excessive collisions, heartbeats received from the 
MAU/ThinMAU (if applicable), and frames received without error. 

The diagnostic waits for the LANIC card to issue a system interrupt 1 
indicating that it has completed the external loopback tests. 
Subsequently, the status register is read for results returned by the 
firmware. If the interrupt is not received, or the number of frames 
received without error is less than four. Step 4 fails. 

For a coaxial cable LAN, a Step 4 failure may indicate a faulty LANIC 
card, AUI cable, MAU/Tap or ThinMAU/BNC-tee (as appropriate), or 
the coax cable. Using a loopback hood and this test, or Test #16, the 
fault may be isolated. 

For StarLAN, a Step 4 failure may indicate a faulty card, StarLAN 
cable, or StarLAN Hub. Using a StarLAN loopback connector and this 
test, the fault can be isolated. See Figure 4-4. 

For either type of LAN, a Step 4 failure may indicate excessive traffic 
on the LAN. 
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NOTE 

For HP StarLAN connections, the following steps in Test #14 are not performed. 



Step 5: For coaxial cable LANs, the diagnostic checks the number of times a 
heartbeat was detected in Step 4. A heartbeat should be detected after 
each successful transmission. If a predefined number of heartbeat 
errors occur, Step 5 fails. 

A Step 5 failure most likely indicates a MAU/ThinMAU fault. 
However, it can also occur for AUI cable or LANIC card faults. Use a 
loopback hood with this test, or Test #16 (Hood Loopback Test), to 
help identify the failure. 

Step 6: For coaxial cable LAN connections, the diagnostic instructs the LANIC 
to run the jabber test. The jabber test involves transmitting frames that 
exceed allowable frame lengths, and monitoring the Control In (CI) 
signal pair for MAU/ThinMAU jabber operation. 

The SQE disable function of the LANIC card is also tested at this time. 

Finally, the firmware resets the MAU/ThinMAU by cycling the power. 
The CI signal pair is checked to verify that jabber operation in the 
MAU/ThinMAU has been reset. 

While the firmware executes this test, the diagnostic is waiting for a 
system interrupt 1, indicating that the test has completed. After it 
detects the interrupt, or a time out occurs, the status register is read for 
test results returned by the firmware. 

If the interrupt was not detected within a predefined time interval, or 
a jabber condition was detected too early in the test process, Step 6 
fails. 

A Step 6 failure suggests a LANIC card or MAU/ThinMAU fault. A 
loopback hood with this test, or Test #16 (Hood Loopback Test) should 
be used to isolate the faulty unit. 
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Step 7: From Step 6, the diagnostic checks whether the jabber condition was 
detected in the jabber test. If the test completion system interrupt was 
not detected, or the jabber condition did not occur, Step 7 fails. 

A Step 7 failure most likely indicates a MAU/ThinMAU fault. 
However, LANIC card or AUI cable faults are possible. Use a 
loopback hood with this test, or Test #16 (Hood Loopback Test), to 
isolate the faulty unit. 

Step 8: The diagnostic checks whether the jabber condition could be reset by 
cycling the power to the MAU/ThinMAU. If the jabber condition was 
never detected then the results from this test are invalid. 

If the test completion system interrupt 1 was not detected, or the 
jabber condition appears to be active after MAU/ThinMAU power 
cycling, Step 8 fails. 

A Step 8 failure suggests that LANIC card or MAU/ThinMAU are 
faulty. Use a loopback hood with this test, or Test #16 (Hood 
Loopback Test) to help isolate the fault. 

Step 9: The diagnostic checks whether the SQE disable function is operating 

properly. If either the system interrupt 1 was not detected in Step 6, or 
the firmware reports a failure in the SQE disable test. Step 9 fails. 

A Step 9 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 
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StarLAN Connection Fault Isolation Procedures 

Using a StarLAN loopback connector (see Figure 4-4), part number 5061-4977, 
Test 14 is used to isolate faulty FRUs on StarLAN connections. The procedure 
is illustrated in Figure 4-5, and described below. 
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Figure 4-4. StarLAN Loopback Connector 



Test A . With the connection set up as in Figure 4-5, "Test A Configuration", Test 
14 is run. If Test 14 fails, the LANIC card, StarLAN cable, or StarLAN Hub may 
be faulty. Proceed to Test B. 

Test B . Disconnect the StarLAN cable from the LANIC, and replace it with the 
StarLAN loopback connector, as shown in the "Test B Configuration". Test 14 is 
again run. If Test 14 fails, the LANIC card is faulty and should be replaced. If 
it passes, the LANIC card is good, so proceed to Test C. 

Test C . If Test 14 passes the "Test B Configuration", try the configuration in the 
"Test C Configuration". The StarLAN cable is reconnected to the LANIC card. 
At the Hub end, the StarLAN cable is disconnected from the Hub, and attached 
to the StarLAN loopback connector. Then, Test 14 is repeated. 
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NOTE 



Because the maximum distance between a StarLAN node and Hub is 250 metres, 
Test C results are reliable for cables up to 125 metres only. Where StarLAN 
cables exceed this distance, use of the loopback connector in the "Test C 
Configuration" is not supported. Instead, use of a known good Hub substituted 
for the existing Hub may be required. 



If Test 14 passes, the LANIC card and cable are good, and a fault exists on the 
Hub or some other part of the StarLAN. Refer to the HP StarLAN Diagnostics 
and Troubleshooting Manual for PCs (50906-90060) for isolating StarLAN 
hardware faults. 
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Figure 4-5. StarLAN Connection Fault Isolation Using Test 1 4 
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Test #15. Date Code Test 



Test #15 verifies that the LANIC card and ROM firmware are current. Because 
this test depends on a properly operating LANIC card, it is performed after Tests 
1 through 14. 

This test uses the dump hardware kernel command to read the ROM and LANIC 
card date codes. It consists of 3 steps: 

Step 1: The diagnostic first resets the LANIC card and enables the LANIC 
card master handshaice. It then issues the dump hardware kernel 
command and waits for a system interrupt 1, which indicates that the 
dump is complete. The diagnostic finally moves the dump from the 
extra data segment to the stack. 

If any of the following occurs, Step 1 fails: 

- the interrupt was not detected. 

- the kernel command was not issued successfully, or 

- the data move from the data segment to the stack failed. 

A Step 1 failure most likely indicates a LANIC card fault. Replace the 
LANIC card. 

Step 2: The diagnostic checks the ROM date code against the expected date 
code hardcoded in the diagnostic. If the ROM date code is earlier in 
the time then the date code expected, Step 2 fails. 

A Step 2 failure indicates that the LANIC is either an outdated card, or 
the dump failed. In either case replace the LANIC card. 

Step 3: The diagnostic checks the board date code against expected date code 
hardcoded in the diagnostic. If the board date code is earlier in time 
then the expected date code, Step 3 fails. 

A Step 3 failure indicates that the LANIC is either an outdated card, or 
the dump failed. In either case replace the LANIC card. 
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Test #16. Hood Loopback Test 



NOTE 



Test #16 is not executed with HP StarLAN connections. Attempts to do so will 
result in the following message: 

Test 16 is not valid for HP30265A StarLANIC 



Test #16 is used on coaxial cable LAN connections, and helps identify the faulty 
units associated with an external loopback (Test #14) failure. This section 
contains the following information: 

• Required Hardware 

• Functional Description 

• Using Test 16 



Required Hardware 

For isolating faults with Test 16, the following hardware is required: 

Part 

Number Description 

30241 A Known good MAU or ThinMAU, for ThickLAN or 

28641 A ThinLAN connections, respectively. 

92257B Terminated loopback hoods for ThickLAN or ThinLAN 

92227Q connections, respectively. See Figures 4-6 and 4-7. 

30241-60009 Known good AUI cable for connecting the 

MAU/loopback hood. 

30241-60002 For Series 39/40/42/52, known good Internal Cable, 

LANIC card to Junction panel. (Used to distinguish 
LANIC card faults from internal cable faults.) 

30241-60003 For Series 44/48/58/6X/70, known good Internal Cable, 

LANIC card to Junction panel. (Used to distinguish 
LANIC card faults from internal cable faults.) 
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Figure 4-6. Loopback Hood on MAU 
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Figure 4-7. Loopback Hood on ThinMAU 
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Functional Description 

Test 16 is an interactive test with its own user interface. After Test 16 is 
specified, and the GO command is issued, the following menu is displayed, 
followed by the Test 16 prompt: 



HOOD LOOPBACK TEST 

1. Test LANIC interface and AUI (25 ohm termination) 

2. Test for collision detection (50 ohm termination) 

3. Test coax interface (MAU on coaxial cable) 

4. Hood Test done, return to main menu 

Please select test format by number 

TEST 16 > 



A test or action is selected by entering its identification number at the Test 16 
prompt. For example, 

TEST 16 > ^ 

will select the "LANIC interface and AUI (25 ohm termination)" test 

The tests listed above are described briefly in the following paragraphs. 



1. Test LANIC interface and AUI (25 ohm termination) 

This test is useful for evakiating the LANIC card to AUI cable interface, and 
individual sections of AUI cable. 

To perform this test, a a known good MAU/ThinMAU with terminated 
loopback hood is substituted for the installed MAU/ThinMAU. Fifty (50) ohm 
terminators must be installed on each end of the loopback hood, resulting in an 
effective resistance of 25 ohms to the MAU/ThinMAU. 

This test is comprised of the following subtests: 

a. LANIC power switch (supplies power to the MAU/ThinMAU) 

b. Test frame loopback from MAU/ThinMAU 

c. MAU/ThinMAU jabber detection 

A typical output from this test is as follows: 



MAU POWER SWITCH STATUS 
The MAUPON signal is TRUE, expecting TRUE 
The MAUPS (v12_Sense) signal is TRUE, expecting TRUE 
The number of power-on tries is 1, expecting fewer than five. 

FRAME LOOPBACK STATUS 
The number of correctly received frames is 8, expecting 8 
The number heartbeats detected is 7, expecting 7 
The number collisions detected is 0, expecting 
The number of times the backoff retry limit was exhausted is 0, expecting 

JABBER STATUS 
MAU Jabber was detected correctly. 
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2. Test for collision detection (50 ohm termination) 

This test is useful for verifying the collision detection capability of the node. 

To perform this test, a loopback hood is attached to either the installed 
MAU/ThinMAU, or a known good MAU/ThinMAU substituted for the installed 
unit. One of the 50 ohm terminators on the loopback hood is is removed, leaving 
the remaining 50 ohm terminator in series between the coaxial cable conductors. 

Collision detection tests include: 

1. Detection of collision signal levels on the coax by the MAU/ThinMAU, 

2. Reporting of collisions by the MAU/ThinMAU via SQE signals on the CI 
pair, 

3. Transmission of SQE signals from the MAU/ThinMAU to the LANIC card 
via the CI pair, 

4. Detection and recognition of SQE signals by the LANIC. This test is 
composed of the following subtests: 

a. LANIC card power switch to MAU/ThinMAU, 

b. Test frame loopback from MAU/ThinMAU (note that a collision is 
expected for every attempted transmission). 

A typical output from this test is as follows: 



COLLISION STATUS 
The number of correctly received frames is 0, expecting 
The number of collisions detected is 128, expecting 128 
The number of times the backoff retry limit was exhausted is 8, expecting 8 



LAN Node Diagnostic 
4-56 



3. Test coax interface (MAU on coaxial cable) 

This test serves as a final evaluation of the node connected to the network coax. 
Faults associated with a coaxial cable Tap (for ThickLAN connections), or faults 
external to the node (i.e., network faults), can be detected. 

This test is comprised of the following subtests: 

a. LANIC power switch (supplies power to the MAU/ThinMAU). 

b. Test frame loopback from a MAU/ThinMAU connected to the network. 

A typical output from this test is as follows: 



MAU POWER SWITCH STATUS 
The MAUPON signal is TRUE, expecting TRUE 
The MAUPS (Vl2_Sense) signal is TRUE, expecting TRUE 
The number of power-on tries is 1, expecting fewer than five. 

FRAME LOOPBACK STATUS 
The number of correctly received frames is 8, expecting 8 
The number of heartbeats detected is 7, expecting 7 
The number of collisions detected is 

(expected value depends on the amount of network traffic) 
The number of times the backoff retry limit was exhausted is 

(expected value depends on the amount of network traffic) 
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Using Test 16 

In this section, general procedures are provided for using Test 16. Once 
understood, these procedures can be adapted to the particular installation. 



NOTE 



The following discussion presumes that Test 14, loopback test, failed. Be sure to 
check the node connections before proceeding with the procedures below. 



Procedure 1 - Part A 

Attach a terminated loopback hood to a known good MAU/ThinMAU. Connect 
this assembly to the LANIC card. For MAU connections to Series 
39/4X/5X/6X/70 systems, a known good AUI cable is required to connect to the 
system junction box (internally connected to the internal cable and LANIC card). 

Run test 1 of Test 16 ("25 ohm termination" test), to exercise the following 
hardware: 

a. LANIC power switch 

b. LANIC AUI driver 

c. LANIC AUI receivers 

d. Internal cable (if applicable) 

Test passes . If test frames are successfully looped back, and MAU heartbeats are 
detected, the LANIC-to-AUI interface circuitry (including the internal cable, if 
applicable) is functioning properly. 

Proceed to Part B of Procedure I. 



Test fails . Check for the following failure conditions: 

- The number of correctly received frames is less than 8 (< 8), but heartbeats 
detected equals 8 (= 8). This suggests a faulty LANIC card Data In (DI) 
receiver or a faulty internal cable Dl signal pair. 

- The number of heartbeats detected < 7, but the correctly received frames = 
8. This suggests a faulty LANIC card Control In (CI) receiver, or a faulty 
internal cable CI pair. 

- The number of heartbeats detected < 7, and the correctly received frames < 
8. This suggests the following faults may exist: 

* LANIC card power switch, 

* LANIC card Data Out (DO) driver, 

* Internal cable DO pair, 

* Internal cable power pair (assuming only a single failure). 

- The number of received frames < 8, and number of collisions > 0. This 
suggests the MAU/ThinMAU and loopback hood are not operating 
properly. 

Since the MAU/ThinMAU and loopback hood are presumed to be good, 
check the loopback hood connection and verify that both 50 ohm 
terminators are securely fastened. 

- Either the MAUPON signal was false, the MAUPS signal was false, or the 
number of power-on retries > 5. This suggests the following faults may 
exist: 

* There is a short between the VP & VC signal lines, 

* The Z80 is unable to turn the power on, 

* The Z80 is unable to detect that the power is on. 

For the failures listed, replace the LANIC card, internal cable, or both. By 
systematically replacing one or the other, the faulty unit can be uniquely 
identified. 



NOTE 



Only authorized service personnel, such as Hewlett-Packard Customer Engineers 
(HP CE) are permitted to access and replace hardware internal to HP 3000 

computer systems. 



LAN Node Diagnostic 
4-59 



Procedure 1 - Part B 

Remove one of the terminators, and run test 2 of Test 16 ("50 ohm 
termination" test). This is a crude verification of the collision detection and 
indicator circuitry of the node. 

Test passes . If the number of times the back off retry limit is exhausted is 8 then 
collision detection circuits are functioning properly. Go on to Procedure 2. 

Test fails . If the retry limit is exhausted is not 8, then the collision detection 
circuits are faulty. Since the MAU/ThinMAU and loopback hood are presumed 
good, check their connection. Since they must operate properly for remaining 
tests, replace them if there are doubts. If the test continues to fail, systematically 
replace the LANIC card (and internal cable, if applicable) until the test passes. 



Procedure 2 

Procedure 2 primarily addresses ThickLAN connections where multiple AUI 
cables may be installed. 

Attach the known good MAU and loopback hood to the end each section of 
AUI cable starting with the one connected directly to the host. For each section 
of AUI cable, run test 1 of Test 16 (the "25 ohm terminator" test). Figure 4-8 
illustrates this process. 
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Figure 4-8. Testing AUI Cable Sections 



Test passes . If the number of correctly received frames = 8, and the number of 
heartbeats detected = 7, the test passes. Consequently, the AUI cable under test is 
presumed good. 
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Test Fails . Check for the following failure conditions: 

- The number of correctly received frames is less than 8 (< 8), and the 
number of heartbeats detected equals 7 (= 7). This suggests a faulty DI 
signal pair of the AUI cable. 

- The number of correctly received frames = 8, and the number of 
heartbeats detected < 7. This suggests a faulty CI signal pair of the AUI 
cable. 

- The number of correctly received frames < 8, and number of heartbeats 
detected < 7. This suggests a faulty DO signal pair, or faulty power pair 
the AUI cable. 

- MAUPON or MAUPS indicates "false", or the number of power-on 
retries > 5. This suggests a short circuit between the VP & VC lines in the 
AUI cable under test. 

After all AUI cable sections have been tested and presumed good, proceed to 
Procedure 3. 



Procedure 3 

Procedure 3 addresses MAU/ThinMAU or coaxial cable faults. 

Attach a loopback connector to the original MAU/ThinMAU. Using this 
assembly in place of the known good MAU/ThinMAU, repeat Procedure I, Parts 
A and B, to verify operation of the MAU/ThinMAU. 

Test passes . If errors are not indicated, the MAU/ThinMAU is presumed good, 
and the fault is presumed to be elsewhere on the LAN cable (e.g., a Tap/BNC tee, 
cable or remote node fault). You will need to perform other tests, (see "Other 
tests", below). 

Test fails . If errors occur, replace the MAU/ThinMAU, reconnect the node to 
the network, and run test 3 of Test 16. 

Other tests . To test the original Tap, try moving to some other node location (i.e., 
some other Tap) on the same coax, and run test 3 of Test 16. If no errors are 
indicated, the original Tap is probably faulty. If errors persist, the original Tap is 
probably good, and the fault exists elsewhere (coax cable or other node). 

To troubleshoot the coax network, refer to the LA N Link Hardware 
Troubleshooting Manual (5955-7681). 

After the network fault is corrected, reconnect the local node and verify 
operation by running test 3 of Test 16. 
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Test #17. Remote Node Test 



Test #17 allows the user to send frames to, and receive frames from, remote 
nodes on the network. This test assists in diagnosing network faults that lie 
outside of the local node hardware. Such faults include: 

- topological problems 

- faulty hardware in the remote nodes 

- network performance degradation 

This section contains the following information: 



• Requirements 

• Functional Description 

• Interpreting Test 17 

Requirements 

Before running Test 17, there are various requirements that must be met. 

Local Node Requirements . 

- LDEV number. You must know the LDEV number of your LANIC card. 

- "AVAILABLE" state. If your LANIC card is not "AVAILABLE", that is, 
the line is "DISCONNECTED" or "CLOSED", you must shut down LAN 
activity on your computer. 

- Good node hardware. Using other diagnostic tests, the operation of the 
local node hardware has been verified (i.e., good LANIC card, AUI or 
StarLAN cables, MAU/ThinMAU as appropriate). 

- LANDIAG tests 1-15. In a given LANDIAG session, the default series of 
tests. Tests 1 through 15, must have been run prior to Test 17. 
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Remote Node Requirements . 

- Station (link-level) address. You must know the 12-digit hexadecimal 
station address of the remote LANIC card. The best source for this 
information is the Network Map. 

The station address of the remote node can be determined through the use 
of software on the remote node. Since you cannot use LANDIAG3000/V 
to remotely determine this address, you must be at the remote computer to 
identify the station address. 

If your remote computer is a Hewlett- Packard personal computer (or 
equivalent) supported on the network, use the DIAGNET or DIAGLINK 
utility to find the station address (refer to the HP Star LAN Diagnostics 
and Troubleshooting Manual for PCs, 50906-90060, or the HP Thin LAN 
Diagnostics and Troubleshooting Manual for PCs, 50909-90060). 

If the remote computer is an HP 3000 MPE-V system, use the 
LANDIAG3000/V "HELP" command. 

- If the remote computer is an HP 3000 MPE-V system, its response to the 
RNT requires its driver be active. The driver is active if 

a. a network service must be running (e.g., NS3000/V) and have control 
of the LANIC card, or 

b. a Test 17 must have been initiated but held in a wait state (waiting 
for a carriage return that actually starts the transmit/receive process). 
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Functional Description 

Remote Node Test examples are provided below. The examples presume that 
Tests 1 through 15 have been completed. Underlined text indicates user input. 
Refer to these examples during the discussion that follows. 



EXAMPLE. Remote Node Test - Normal Completion 



> TEST 17 

> GO 

Please enter the station address of the destination node. 

MARKETING 

A twelve digit hexadecimal number is required. 

Please enter the station address of the destination node. 

0800 0901 1806 

Attempting to open LANIC driver ... please wait 

Driver now ready to echo link level packets. 

! is displayed for each test packet looped back successfully. 
# is displayed for each failure to loop back a test packet. 

Hit return to initiate looping of test frames (1000 max), 
use <control-y> to stop. 

[RETURN! 



100% of the test frames were acknowledged. (1000/1000) 
The average response time was 208 milliseconds. 
End of Pass 
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EXAMPLE. Remote Node Test - Nonexistent Remote Node 



> GO 

Please enter the station address of the destination node. 

0800 0900 A208 

Attempting to open LANIC driver . . . please wait 
Driver now ready to echo link level packets. 

! is displayed for each test packet looped back successfully, 
# is displayed for each failure to loop back a test packet. 

Hit return to initiate looping of test frames (1000 max), 
use <control-y> to stop. 
IRETURNI 



#§### (CONTROP Y 



% of the test frames were acknowledged. (0/5) 
End of Pass 



LAN Node Diagnostic 
4-66 



EXAMPLE. Remote Node Test - Degraded Performance or Network Problem 



> GO 

Please enter the station address of the destination node. 

0800 0900 EF08 

Attempting to open LANIC driver ... please wait 

Driver now ready to echo link level packets. 

! is displayed for each test packet looped back successfully 
# is displayed for each failure to loop back a test packet. 

Hit return to initiate looping of test frames (1000 max), 
use <control-y> to stop. 

[RETURN! 



\ \\jf§\\ \\§\ \\ WjfW §§§ !!!!!#!!!!!! [controlI Y 



76% of the test frames were acknowledged. (25/33) 
The average response time was 201 milliseconds. 
End of Pass 



General Information 

You must be able to access and exit the test, select the remote node with which 
to run the test, and obtain test results. Note the following: 

- Driver statistics are not provided; they can be obtained via the SHOWCOM 
command from MPE (see Chapter 2). 

- All terminal I/O is echoed to the list file, consistent with the rest of the 
diagnostic. This presumes the NOPRINT facility was not activated. 

- The LOOP and NOPRINT facilities are disabled for Test 17. 
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Accessing the Remote Node Test 

Before accessing the Remote Node Test, ensure all requirements listed in the 
"Requirements" section have been met. 

To run the RNT, specify Test 17 in a TEST command ( > TEST 1 7 ), and 
follow it with a GO command. Consistent with the diagnostic, subsequent GO 
commands will rerun Test 1 7 if it was the last test specified. 

After the GO command is issued, the user is prompted for the station address of 
the remote node. The diagnostic expects a 12-digit hexadecimal number for the 
station address (upper or lower case characters are accepted). Leading, trailing 
and embedded blanks are permitted, as illustrated by the following examples: 

hh hh hh hh hh hh 
hhhh hhhh hhhh 
hhhhhhhhhhhh 

where h is a hexadecimal digit. 

If an improper user entry is made, the following message is returned: 

A twelve digit hexadecimal number is required. 

followed by another prompt for a station address. 

If a proper station address is not supplied after four attempts, the diagnostic 
issues the following message: 

Bad input - I assume you want the main menu. 

and returns to the LANDIAG command prompt, ">". 

Nonexistent Nodes. If a 12 digit hexadecimal number is entered, no further error 
checking is performed. Thus, a proper entry may not be a valid one, that is, 
there may be no node on the network with the station address specified. The 
diagnostic will still try to send test packets to the address entered. Response 
frames will not occur, and the "no-reply" timer will expire, resulting in a failure. 



NOTE 



Test 17 does not distinguish between remote nodes that are broken, too busy to 
respond, isolated by a network fault, or nonexistent 
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Initiating Transmissions. After a proper station address is entered, the LANIC 
card driver is activated, and the user is directed to "Hit return" to start test 
frame transmission and reception. 



NOTE 



If (RETURN) is not entered, Test 1 7 is idle. The ability to have Test 1 7 idle, that is, 
to open the driver without actually transmitting test frames, is a necessary 
feature for MPE V systems. This is especially true when the system does not 
have network services installed and is the remote node in a Remote Node Test. 

On an MPE V system, the LANIC driver must be active with buffers ready 
before frames can be received or transmitted. If a remote HP 3000 does not 
have network services installed, it can run Test 1 7 to activate the driver yet 
remain in an idle state. In this way, it can respond to test frames transmitted by 
the local node on which Test 1 7 is active. 



Once IRETURNI is entered, the diagnostic begins sending test frames to the node 
specified and checks for proper response frames. 

A test frame transmission and associated response frame reception constitutes a 
single test cycle. Each test cycle should be identical to all others. Up to 10 00 
test cycles are attempted unless the diagnostic is interrupted with a [C0NTR0L)Y. If 
a ICONTROLI Y is issued during an individual test cycle, the diagnostic will allow that 
test cycle to complete before exiting the test. 



Activity Indicator 

During each test cycle, either a response frame is received, or a timer within the 
diagnostic expires. A response frame properly received results in a "!", while an 
improper frame or frame not received results in a "#" character. 

The return of these characters allows the user to know that the diagnostic is 
running properly. 
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Test Results 

Test 1 7 Results. When Test 1 7 completes, either normally or by a " 1 CONTROL l Y". 
the results of the test are summarized. The following is returned: 

- Percent of test frames transmitted that were properly acknowledged. The 
actual numbers are also indicated in a ratio format. 

- Average response time for response frames acknowledged. This is returned 
only if there were response frames received. 

Driver Statistics. The LANIC card driver collects useful statistics about the 
node's use of the network. This includes counts of overruns, underruns, CRC 
errors, retransmissions required, etc. LANDIAG does not provide this data to the 
user; the data is accessed via the SHOWCOM command with the ERROR parameter 
from MPE, as follows: 

: SHOWCOM LDEV\ ERROR 

Test 1 7 resets all the statistics. Therefore, for long term intermittent error 
analysis, use SHOWCOM prior to Test 17. 

During a network fault isolation process, use SHOWCOM after Test 17. The 
statistics will describe only those network events that have taken place since the 
last time the driver was opened. 



NOTE 



For more information on SHOWCOM, see Chapter 2. 



Interpreting Test 17 

Performance degradation between two nodes can occur from hardware or 
software faults, extremely busy nodes, or excessive traffic on the network. Test 
17 can indicate degraded performance if either of the following result: 

- Less than 95% of properly transmitted test frames result in proper 
responses. 

- The average response time is more than 550 milliseconds. 

On a small network. Test 17 can be run using all remote nodes. On a large 
network, however, a sampling of nodes might be more appropriate. When 
sampling, select nodes that are both near and far, where distance is measured by 
lengths of network cable a frame must traverse. For problems with a specific 
node, run the Remote Node Test with that node. 

For network fault isolation, you should refer to the appropriate LAN 
troubleshooting manual: 

- LAN Link Hardware Troubleshooting Manual, 5955-7681, for IEEE 802.3 
coaxial cable LANs, 

- HP Star LA N Diagnostics and Troubleshooting Manual for PCs, 
50906-90060, for IEEE 802.3 twisted pair HP StarLAN. 



However, the results of Test 1 7 tests may suggest possible faults that can be 
further investigated directly. For example, consider the following: 

1. A series of Remote Node Tests indicates that only one remote node is 
faulty. 

At the faulty node, determine whether NS3000 is up. 

Run LANDIAG on that node. Verify that all node FRUs on that system are 
operating properly. 

If the remote node is connected to a coaxial cable LAN, check for a 
"marginal" MAU/ThinMAU. A node containing a marginal 
MAU/ThinMAU can communicate with nearby nodes, but cannot 
communicate with distant nodes. If LANDIAG Test 16 (MAU loopback) 
passes while Test 17 (Remote Node) fails for distant nodes only, the 
MAU/ThinMAU should be replaced. 
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2, Communication is difficult or impossible with every node. 

The local node may have a defective FRU. Ensure other tests of 
LANDIAG have already been run and passed. 

If the local node is connected to a StarLAN, check for a damaged cable or 
faulty Hub. 

If the local node is connected to a coaxial cable LAN, check for a marginal 
MAU/ThinMAU (Test 16 passes, Test 17 fails for distant nodes only). 
Check for loose connectors or terminators. Check the coaxial cable for 
damage -- it may be severed, crimped or frayed. 

If you have one, a Time Domain Reflectometer (TDK) can be used to test 
the coax to locate cable faults. Also, useful information can be gained by 
measuring the resistance across the contacts at the nearest Tap: 

a. A resistance of about 25 to 30 ohms between the center conductor and 
braided shield is acceptable. 

b. A resistance of 50 ohms suggests that one termi-nator is absent or that 
there is an open circuit somewhere in the coax. 

c. A very large resistance suggests that both terminators are absent. 

d. A very small resistance suggests a short between the shield and the 
center conductor. 

For resistance faults that are difficult to find, TDK testing is recommended 
(see the LAN Link Hardware Troubleshooting Manual, 5955-7681, for more 
information). 

3. Test 1 7 results indicate poor response from several adjacent nodes. 

For StarLAN connections, the Hub to which the remote nodes are 
connected is probably faulty. 

For coax connections, the coax may be partially damaged between a node 
that successfully responds and one that does not. 
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4. For coax connections, Test 17 results indicate performance degrades steadily 
with distance from the local node. 

The local node probably has a marginal transmitter. Replace the 
MAU/ThinMAU at the local node. 

5. All nodes were checked with Test 17, and there was no trouble 
communicating with any of them. 

If a communication problem exists, it is likely due to a software fault in a 
user application. 

6. Test 17 could not send out any test frames. 

a. For some reason, LANDIAG may not have been able to open the 
driver. (A CS error code will be returned if this is the case.) Check the 
following: 

- Ensure that NS3000/V is down, and that no other processes are using 
the LANIC card. 

- Ensure the LANIC card can pass self test, which is a prerequisite for 
opening the driver. Selftest failures are commonly due connection 
faults between the LANIC card and the LAN. 

b. The diagnostic may have been unable to obtain an extra data segment 
to use as a frame buffer. This condition points to a software error. 

7. If Test 17 returns a message indicating that Tests 1, 2, 9 and 10 before Test 
17 can be run, perform these LANDIAG tests. 
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Error Messages 

The following is a list of error messages associated with LANDIAG. 

• There is no LANIC present at that location. 

The LDEY specified by the user does not respond to a roll call during 
initialization. 

•The diagnostic needs driver version B011000 or newer. 

Software compatibility must be maintained between the diagnostic and the 
driver. However, it may be possible to continue diagnostic testing in spite of this 
warning. 

• The LANIC could not be allocated. 

Network Services (NS) is probably running. NS has already allocated the LANIC 
and has not released it. 

• An extra data segment could not be created. 

This reflects an operating system problem or a system resource shortage. 

• That LDEV is not configured as a LANIC. 

The LDEV entry in the I/O configuration table is not a LANIC of type 17, 
subtype 9. 

•OP, DI, or SM capability needed to run diagnostic. 

Have the system manager provide you DI (diagnostician) capability. 

• The output file could not be opened. 

Logging of diagnostic results to an output file is disabled, but the diagnostic can 
still be run. 
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• Diagnostic not designed for HP3000/30 or 33. 

Diagnostic test results on Series 30/33 systems may not be valid; LAN services are 
not supported on Series 30s or 33s. 

• Bad input - Try again or enter "Help". 

Command entry error. The HELP message includes a list of all the commands. 

•Test's parameter must be 1 to 17 or "ALL". 

Parameter error on a TEST command. Note that "ALL" includes Tests 1-15 only. 
"ALL" is default if no parameter is provided. 

• Exit failed to return all resources. 

This reflects an operating system problem. 

• Bad input - I assume you want the main menu. 

Improper parameter entered in Tests 16 or 17 more than three consecutive times. 
Returns to LAND! AG prompt ">". 

• A small integer input was expected. Please retry. 

Test 16 prompt expects input range 1 through 4. Non-numeric character entry 
was made. 

• Test 1 must run for this test to run. 

Test dependency message. 

• Test 1 and 2 must pass for this test to run. 

Test dependency message. 

• Test 1,2,9 and 10 must pass for this test to run. 

Test dependency message. 
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• A twelve digit hexadecimal number is required. 



For Test 1 7 (Remote Node Test), a proper station address must be entered. 
Leading, trailing and embedded blanks are permitted. Upper and lower case 
characters are accepted. 



• MPE commands are not permitted. 



Access to MPE, via a colon (;) followed by an MPE command, during a 
LANDIAG session is not permitted. 



This test can't run while NS/3000 is up. 



With NS running and in control of the LANIC card, Tests 3 through 1 7 cannot 
be initiated. 



• You must have CS capability to run this test. 

For Test 1 7, capability to use the Communication Subsystem is necessary. 



• You must specify an individual address. 

(The first byte of the address must be even). 



For Test 17, a proper station address must be entered. The address cannot be a 
group address, that is, its first byte cannot be an odd value. 



Test 16 is not valid for the HP30265A StarLANIC. 



Test 16 does not apply to systems with HP StarLAN connections. Use Test 14, 
instead. 
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LANIC Self Test 



The LANIC card contains a self test routine in ROM. An understanding of this 
self test can help you identify whether or not a LANIC card is faulty and 
requires replacement. For more information on LANIC card self test, refer to 
your LANIC card installation and service manual. 



The Scope of LANIC Card Self Test 



The LANIC card self test checks the operation of the card and LAN connection 
hardware. 

The hardware tested depends partially on the type of LAN card connection: 
coax cable LAN, or HP StarLAN. The following circuitry is common to both 
types of LAN cards: 

• Microprocessor and associated circuitry 

• ROM 

• RAM 

• Timer [Chip] 

• FIFOs [Receive Data Buffers] 

• Protocol Controller [82586 Chip] 



Card specific circuitry tested includes: 
Coax LAN card 

• MAU Power Circuitry 

• Analog Driver [8023] 

StarLAN card 

• StarLAN media interface [7960] 

By testing the above circuitry, the operation of the LANIC card's main module 
(all circuitry not associated with the SIMB/IMB interface) is verified. 

In addition, the self test performs an external loopback test to verify the 
card-to-LAN interface. If the card is not connected to its respective LAN, the 
self test will fail this portion of the test. 
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Self Test Limitations 



The following LANIC card circuitry or functions are not tested by self test. 
However, these items can be exercised by using LANDIAG3000/V (see Chapter 
4). 

• IMB/SIMB Interface, including data and address lines 

• Master and slave handshakes 

• Interrupt mask flipflop 

• Z80/82586 to master handshake arbitration 

• Slave handshake vs Z80 arbitration (system accesses) 

• Slave handshake vs Z80 arbitration (I/O) 

• 82586 collision recovery, and identification of bad packets 

• Collision detect or jabber functions 



How To Read Selftest LEDs 



There are 15 LEDs located on the edge of the LANIC card, eight of which are 
accessed by the self test. For location and identification of these LEDs see 
Chapter 3. 

The eight LEDs used by self test are labeled H to N, and "*". These eight LEDs 
are also labeled with mnemonics to indicate their function during normal 
operation, as follows: 



TX 

RX 

MN 

DL 

RO 

Q 

IT 

ST 



ON when a XMIT command is started 

ON when a RCV command is started 

ON when in monitor mode 

ON when the DOWNLOAD command is started 

ON when ROM-resident firmware is in control 

ON when microprocessor is waiting for a command 

ON when microprocessor is running an idle selftest routine 

ON when self test is running 
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Depending on your particular system, the LED labeled "ST" (the rightmost LED) 
will be in one of three states: off, on, or blinking. 

ST is OFF (applies to all MPE-V systems). 

When the ST is off, self test is not running, and the other seven LEDs perform 

their mnemonic functions as noted above. 

ST is ON (applies to all MPE-V systems). 

However, when ST is on, the self test is in progress. The self test consists of 
many subtests ; while the self test is executing, the remaining seven LEDs are 
used to display a code indicating which subtest is executing. See Table 5-1. 

If the self test completes with no errors, the selftest LED will be on and the 
other seven LEDs will be off (a code of all zeros) for five seconds. After five 
seconds, the self test LED (ST) will go off, and the remaining LEDs perform 
their normal LANIC card functions. 

ST is Blinking . 

If self test fails on Series 39/4X/5X/6X/70 systems, the ST LED will blink slowly, 

and the code of the subtest that failed will be displayed for about 20 seconds. 

The ST LED does not blink on cards installed on Series 37/MICRO3000 systems. 
If self test fails at power-on, a hexadecimal failure code is returned to the system 
console under the heading "Local Area Network Interface Controller". When 
self test is initiated from LANDIAG, failures are reported to LANDIAG (see 
Chapter 4). 
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How To Use the Self Test 
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Invoking Self Test 

Methods of invoking LANIC card self test depends on the computer type. 

LANDIAG . For all MPE-V computer systems, the self test can be invoked by 
LANDIAG Test #4. Refer to Chapter 4. 

Power-On . For all MPE-V computer systems, self test may be manually initiated 
by powering on the computer. 

For Series 39/4X/5X/6X/70 systems, the self test will first blink the 8 self test 
LEDs on and off slowly for approximately 13 seconds, after which self test will 
run. 

For Series 37/MICRO3000 systems, self test will simply run at power up. 

Reset Switch . For Series 39/4X/5X/6X/70 systems, the LANIC card contains a 
LANIC Test Reset Switch located on the card edge. 



CAUTION 



Pressing the reset switch performs a hard reset on the LANIC card before the 
self test is initiated. Be sure that no network activity is in progress that may be 
destroyed by pressing the reset switch. 



To use the reset switch to run the self test, perform the following: 

1. Ensure the LANIC card is not in use. Do a SHOWCOM and look for 
LINE UNCONNECTED, or CLOSED. 

2. Open the computer card cage to observe the self test LEDs. Note the present 
LED indications. If the ST LED is on, and the remaining seven LEDs are 
displaying a steady pattern, make a written record of which LEDs are lit. 
(This information may be needed later if the problem persists beyond the 
initial steps of troubleshooting.) 

3. Press the LANIC TEST RESET switch to initiate the self test. See Chapter 3 
for location of this switch. 



4. Observe the self test LEDs. Refer to Table 5-1 to interpret the various LED 
patterns displayed. 

If the self test completes with no errors, the selftest LED (ST/^) will be on 
and the LEDs H through N will be off (a code of zeros) for about five 
seconds. Then, the ST/^ LED will go off, and LEDs H through N will 
perform their normal operating functions. 

If the self test fails, the code of the test that failed will be displayed by 
LEDs H through N and the ST/* LED will blink slowly for at least 20 
seconds. 

Table 5-2 provides codes for unexpected results from the self test. If such 
an event occurs, the ST/^ LED will be on (not blinking) and LEDS H 
through N will display one of the codes described in Table 5-1. 

5. If the LANIC fails the self test, the failure is most likely in the LANIC card. 
However, failures of tests 36 (24 HEX, MAU Power) or 46 (2E HEX, 
external loopback) may indicate problems with the AUI, MAU, or coax. If 
in doubt, run the self test with a loopback hood, or use LANDIAG 



Looping 

Looping on the self test is useful for catching intermittent errors. 

For all MPE-V systems, selftest looping can be invoked from LANDIAG, using 
the following command sequence: 

> LOOP 1000 

> TEST 4 

> GO 

For Series 39/4X/5X/6X/70 systems, self test may be manually looped by 
continuously depressing the LANIC Test Switch, such as with a clip. The looping 
continues until a error is detected. Self test will halt with the failed subtest 
number indicated by the selftest LEDs. The ST LED will blink until the switch is 
released. 



CAUTION 



If self test is run during normal LAN activity, the LANIC card and network 
operations will cease. Recovery may be possible in higher software levels; 
however, avoidance of this situation is recommended. Results of self test may be 
erroneous. 
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Observing Self Test 

While the self test is cycling through its "subtests", the LEDs will display which 
subtest is running. Refer to the paragraphs under "How to Read Selftest LEDs", 
presented earlier in this chapter. 



Selftest Failure 

With two exceptions, replace the LANIC card if any subtests within the self test 
fail. The exceptions are: 

- Test 36 (24 HEX, MAU Power). Applies to coaxial cable LAN connections 
only. 

- Test 46 (2E HEX, External loopback). Requires connection to the LAN or 
applicable loopback connector to pass. 

Failures of these two tests may require additional troubleshooting using a 
loopback hood and/or LANDIAG. 
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Table 5-1. Selftest LEDs and Subtest Descriptions 



CODE 


SUBTEST 


DESCRIPTION 


DEC 


HEX 
NO. 


LED 
INDICATION 


H 


I 


J 


K 


L 


M 


N 


* 


1 


1 




















1 




Z80 


Instruction set 


2 


2 

















1 







EPROM 


Checksum 


3 


3 

















1 


1 




Station Address PROM 


Checksum 


4 


4 














1 










High Byte Latch 




5 


5 














1 





1 




Byte RAM Data 


Even addresses 


6 


6 














1 


1 







Byte RAM Data 


Odd addresses 


7 


7 














1 


1 


1 




Byte RAM Address 


Incrementing addresses 


8 


8 
























Byte RAM Address 


Decrementing addresses 


9 


9 



















1 




Word RAM 


Address tests 


10 


A 
















1 







Word/Byte Address 


Address mapping 


11 


B 
















1 


1 




Z80 


Memory reference instructions 


12 


C 













1 










MDIAG register 
SYSCON register 


Proper state after reset 


13 


D 













1 





1 




CTC 


Data test 


14 


E 













1 


1 







CTC 


Mode counting 


15 


F 













1 


1 


1 




CTC 


Mode 2 counting 


16 


10 
























CTC 


Mode 4 counting 


17 


11 



















1 




Interrupt PAL 


Bit 4 set and cleared 


18 


12 
















1 







Z80 interrupt 




19 


13 
















1 


1 




Z80 NMI 


Non-Maskable Interrupt 


20 


14 













1 










MHSDIS 


DMA Handshake Disabled 
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Table 5-1. Self test LEDs and Subtest Descriptions (continued) 



CODE 


SUBTEST 


DESCRIPTION 


DEC 


HEX 
NO. 


LED 
INDICATION 


H 


I 


J 


K 


L 


M h 


J ^ 


21 


15 













1 


1 




PADDR to BADDR bus 


Low 15 bits 


22 


16 













1 


1 c 


) 1 


ZBANKL register 


Low Z-80 bank bit 


23 


17 













1 


1 1 




ZBANKH register 


Eight high Z-80 bank bits 


24 


18 















c 


) 1 


Preliminary FIFO 


INREADY, ADVREADY, OUTREADY 


25 


19 















1 




FIFO Data 


BDATA(7) 


26 


1A 















1 c 


1 


FIFO Data 


BEA(7,8) 


27 


IB 















1 1 




FIFO Data 


BDATA(2:6) 


28 


1C 












1 





1 


FIFO Data 


BDATA(0, 1,13:15) 


29 


ID 












1 


1 




FIFO Data 


BDATA(8:12) 


30 


IE 












1 


1 




FIFO Data 


BA(11:15) 


31 


IF 












1 


1 1 




FIFO Data 


BA(6:10) 


32 


20 





















FIFO Data 


BA(1:5) 


33 


21 
















1 




R14 


Configuration register 


34 


22 
















1 




OBII register 


Value; Channel number not 


35 


23 
















1 1 




COMCON register 


Values from reset 


36 


24 













1 







MAU Power 


On/Off (AUI/MAU not required) 


37 


25 













1 


1 




R13 


OR, CR Full Bit 


38 


26 













1 


1 




R15 


Selftest Result register 
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Table 5-1. Self test LEDs and Subtest Descriptions (continued) 



CODE 


SUBTEST 


DESCRIPTION 


DEC 


HEX 
NO. 


LED 
INDICATION 


H 


I 


J 


K 


L 


M 


N 


¥: 


39 


27 













1 


1 


1 


1 


82586 


Interrupt 


40 


28 























82586 


Reset 


41 


29 


















1 




PBUS register 
addressing 




42 


2A 















1 







82586 


RAM addressing 


43 


2B 















1 


1 




82586 


Diagnose 


44 


2C 












1 










8023 


Loopback 


45 


. 2D 












1 





1 




82586 


Write to FIFOs 


46 


2E 












1 


1 







External loopback 


Loopback to/from LAN ^* 



where "^" is the ST (Self Test) LED 

** Note: Failure of this test is normal if the LANIC card is not connected to the LAN or applicable 
loopback connector. 



The final test in Table 5-1, the External loopback test, transmits and receives a 
1148 byte frame on the LAN or loopback connector. The frame contains the 
following information: 

Destination and Source Address fields . These fields each contain the LANIC 
card's 6 byte station address stored in PROM. The first 3 bytes are 00 08 09 
hexadecimal, and the last 3 bytes are identifiable by the 6 hexadecimal digits 
labeled on the PROM. 

Length field . This field consists of 2 bytes indicating the length of the Data field 
(in this case, 1134 bytes) 
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Data field . The data field contains data to be interpreted by the receiving node. 
The first 3 bytes are encoded to indicate the following: 

- The frame is an IEEE 802.3 "TEST Command" frame. 

- A "TEST Response" frame must be returned by the remote node. 

- The command and response is handled at the IEEE 802.3 Media Access 
Control (MAC) layer. For HP 3000 systems, the MAC layer consists of the 
LANIC card and driver. 

Next, the following 31 bytes of ASCII data are provided: 

HP3000 NODE xxxxxxxxxxxx TEST 

where xxxxxxxxxxxx is the station address in ASCII. 

The remaining data consist of 1100 bytes with a binary incrementing pattern. 

Table 5-2. Reporting of Unexpected Results from Self Test 



CODE 


DESCRIPTION OF FAILURE 


DEC 


HEX 
NO. 


LED 
INDICATION 


H 


I 


J 


K 


L 


M 


N 


^ 


122 


7A 













1 







The 82586 failed to clear its command word. 


123 


7B 













1 


1 




Selftest Result register (R15) bit bad. 


124 


7C 










1 










Z80 stack underflow during self test. 


125 


7D 










1 





1 




Unexpected Z80 Non-Maskable Interrupt (NMI). 


126 


7E 










1 


1 







Unexpected Z80 interrupt. 


127 


7F 










1 


1 


1 




The LANIC was reset, but self test never started, 
or LED circuitry failed. 



where "^" is the ST (Self Test) LED 
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Tracing 



General information 



The CS/3000 Trace Facility is used to provide a record of the line actions, CS 
states and events that occur during Network Services operation. When problems 
occur during operation, the trace facility provides the means to pinpoint the 
problem area. For example, suppose you are experiencing a data integrity 
problem between two computers in your network; the information that you send 
to one computer isn't the same information that is being received at the other 
end. A trace could be enabled to monitor the data in your subsystem to try to 
"trap" the data transfer error when it occurs. 

The trace facility is invoked by the operator with a : LINKCONTROL command. 
Tracing can be enabled/disabled when OPENing the line, or before or after the 
line is opened. Tracing can be invoked for any communication line that 
Network Services uses. Once invoked for a particular communications line, the 
trace facility continues to record line activity until the user issues a new 
: LINKCONTROL command with the TRACE=OFF parameter. The trace facility 
keeps track of actions, states and events in the form of trace entries. 

The trace entries are grouped into trace records: one trace record for each CS 
intrinsic called by Network Services. The trace records are permanently stored in 
a system-generated file named LINKTxxx, or in a user-specified trace file. The 
contents of a CS/3000 trace file can be formatted and printed through the use of 
a trace dump utility program. There are two link level trace formatting 
programs for Network Services: CSDUMP and DSDUMP. CSDUMP does some 
formatting and displays all trace file data in a raw form. DSDUMP allows you 
to choose a subset of the trace file to be formatted, and will also analyze the 
chosen data. In addition, CSDUMP will display all of the bisynchronous line 
protocol, while DSDUMP only displays the DS protocol. The trace facility must 
be terminated before CSDUMP and DSDUMP can be run. Refer to the 
Fundamental Data Communications Handbook for additional information on the 
CSTRACE. 
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Linkcontrol Trace=On 



LINKCONTROL TRACE=ON activates the Trace Facility, that is, link-level tracing is 
activated on a communication line's hnk. 



Syntax 



LINKCONTROL Linkl\/ame;JR/\CE=On 

[|ALL] [§Mask] [JumEn tries] [pRAP] [uFileName] 



Parameters 



L inkName 



The configured name in NMMGR of an active data 
communications line. 



ALL Generate trace records for g// line activity. If you omit 

this parameter, only I/O errors are traced. 

Mask An Octal number preceded by a percent sign, %nnn. 

The Mask is used to select the type of trace entries 
generated. Refer to Table 6-2 for a detailed description 
of the Mask parameter protocols. 

Combine these values for Mask: 

?^o001 = Protocol Send Text (PSTX) entries. 

?^o002 = Protocol Send Control (PSCT) entries. 

fo004 = Protocol Receive Text (PRTX) entries. 

foOA = Protocol Receive Control (PRCT) entries. 

5^0040 = Protocol State Transition (PSTN) entries. 

7o100 = INP interconnect entries. 

%200 = Generate IMF (bisync only) control unit state transition entries. 
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numentries 



WRAP 



filename 



The value of entries is used to derive the size of trace 
file record. Trace entries are deposited in a record in a 
circular manner. A driver dependent default of 24 will 
be used if the parameter is omitted. Default = 24. 

Specifies that if the trace record is full for a given CS 
intrinsic, previous entries are overlayed. Its absence 
indicates that succeeding entries will be flushed. This 
parameter does not affect the EOF marker of the file. 

Trace output will be sent to a specified file name which 
has been previously built. If a file name is not specified, 
the default destination will be LINKT/7A7A7, where nnn is 
the MPE logical number of the CS device. If a trace 
file exists, it will be purged and a new trace file will be 
created. 



Discussion 



Example 



Refer to NS3000/V Network Manager Reference Manual (32344-90002). 



: LINKCONTROL NEWYORK;TRACE=ON,ALL , ,24>WRAP>NYC000 

Link level tracing is activated for the NEWYORK CS device. Records of all line 
activity and all trace entries, except for PSTN are generated and sent to file 
NYCOOO in the logon group and account. Each trace record has no more than 24 
entries. Overflow entries overlay prior trace entries. 
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Linkcontrol Trace=Off 



LINKCONTROL TRACE=OFF deactivates the Trace Facility. 



Syntax 



LINKCONTROL LinkMame ;1RACE=0FF 



Parameters 



L inkName 



The configured name of an active data communications 
Hne. 



Discussion 



Example 



This command deactivates link level tracing on the specified communications 
hne. The link must have been started before you can issue this command 
LinkName is NMMGR configuration, not sysdump. 



: LINKCONTROL NEWYORK; TRACE=OFF 

Link level tracing is deactivated for the NEWYORK LANIC. 
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Using CSDUMP Formatting Program 



RUN CSDUMP. PUB. SYS[, OCTAL] [, HEX] 





;PARM=<j 1 



The trace dump program uses the CSTRACE file as input and produces a 
formatted trace listing on the LIST file. 

The secondary entry point OCTAL allows you to specify that all raw data will be 
output in octal, otherwise it will be output in hexadecimal. (The entry point HEX, 
allowing you to specify hexadecimal for the output, has been retained for 
backward compatibility to the time when the default was octal.) If you specify 
PARM=0 or 1 all entries will be output by time; however, if you specify PARM=2 
only CS/3000 intrinsics will be output by time. 

Various conditions can cause this program to abort. These are indicated in an 
information error message, and in parameter values of the QUIT intrinsic shown 
in Table 6-1. 



Table 6-1. CSDUMP Error Message Parameter 



Parameter 


Meaning 


1 


Illegal dump format request 


2 


Open failure on trace file 


3 


Open failure on list file 


4 


Trace file access error 


5 


Open failure on temporary file 


6 


Temporary file access error 


7 


List file access error 
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Defining a Trace File for CSDUMP 



The program expects a trace file named CSTRACE. If your trace file has a 
different name, such as the default file name LINKTnnn, you will need to equate 
the trace file name to CSTRACE. Use the MPE : FILE command this way: 



FILE CSTRACE=LINKTnnn.PUB.SYS 



Defining a CSDUMP Listing File 
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The formal file designator of the trace listing file for CSDUMP is LIST. The file 
may be defined as a CRT terminal, a line printer, or a disc file. To define the list 
file, enter an MPE : FILE command prior to initiating the CSDUMP program. 
Some typical examples are: 

:FILE LIST;DEV=LP LP is assumed to be the device class name for one 

or more line printers. 

:FILE LIST=FILENAME FILENAME is assumed to be the name of an old 

temporary or permanent disc file. 

If a list file does not exist or is not designated by a : FILE command, and PARM 
of the RUN command is not 1, the CSDUMP program employs the user's 
session/job output device as the list file. If PARM is set to 1, then the dump 
program attempts to open the file LIST as an old job or system file. If this fails 
because LIST does not exist, then LIST is opened as a new file in the system 
domain. After the CSDUMP program has run, the contents of this file may be 
accessed via a text editor, such as EDIT/3000. 



Initiation the CSDUMP Program 



After the CSTRACE and LIST files have been defined, enter the following 
command: 

PI 

:RUN CSDUMP. PUB. SYS[, OCTAL] [;PARM=n >] 

The trace dump program uses the CSTRACE file as input and produces a 
formatted trace listing on the LIST file. The format of the trace listing is 
described in the following text. If the secondary entry point OCTAL is specified 
when CSDUMP is run, the numeric codes for both control characters and data 
will be printed in octal instead of hexadecimal. If you specify PARM=0 or 1, all 
entries will be output by time; however, if you specify PARM=2 only CS/3000 
intrinsics will be output by time. 



Formatted CSDUIVIP Trace Listing 



A CSDUMP Trace listing has a specific format. The components of a Trace 
listing are a header message; the beginning-of -trace message; the opening Line 
Information Display box; a series of trace records, each consisting of a record 
header and one or more consecutively numbered entries; an end-of -trace message; 
and the closing Line Information Display box. These components are discussed 
in detail on the following pages. The examples of the various components are 
taken from a trace of a line connected to a LANIC. 
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CSDUMP Listing Header IVIessage 



NOTE 



Items under discussion are shaded for easy identification. 



At the start of the trace listing is a header message (Figure 6-1) that tells the date 
and time of day when the listing was printed and the fully-quahfied name of the 
trace file. The meanings of the two remaining items in the header message are: 



Item 

LAST OPENED ON .. 

SYSTEM ID=v.uu.ff 



Meaning 

This tells you the date and time of day 
when the trace was executed. 

This tells you the version (v), update level 
(uu) and the fix level (f f) of the MPE 
operating system that was being used when 
the trace was performed. 



OS TRACE ANALYZER (B. 00.23) HON, JUN 6, 1984, 11:48 AM 

TRACE FILE IS LINK36.PUB.SYS 
ALL ENTRIES DUMPED BY TIME 

LAST OPENED ON MON, APR ^Q, 1984, 11;46 AM 

SYSTEM ID=00.20 



Figure 6-1. Trace Listing Header 
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Begin Tracing and Line Information Messages 



The BEGIN TRACING. . . message appears in the listing when the line to be 
traced is opened. The message tells you the decimal logical device number of the 
line (36 in the example in Figure 6-2). It indicates the line's activities are now 
being monitored by the trace facility. It is followed by the Line Information 
Display describing the state of the line when tracing started. 

M. \/. .x/ .V. .V. .V. .V. .V. .V. .V. .V. .V. .V. .V. .V. .V. .V. .V. .V. .V. V. .V. v. .V. ,v. .V. .V. .V. .V. .V. .V. 

^ BEGIN TRACING FOR iESiii© * 
*-L-I-N-E---I-N-F-0-R-M-A-T-I-0-N---D-I-S-P-L-A-Y^ 



^ 


LINE NUMBER 


;: 3 LOGICAL DEV. NUMBER: 36 


^ 


^ 


DEV. TYPE; 


17 SUBTYPE: 3 VER: x.55.23 


^ 


^ 




0123456789012345 


^ 


¥r 


COPTIONS: 


0000100010000010 


¥: 


^ 


AOPTIONS: 


0000000100001101 


^ 


^ 


DOPTIONS: 


0000010000000000 


^ 


^ 


NETWORK'ID: 


0000000000000000 


^ 


^ 


NUMBUFFERS: 


1 BUFFSIZE: 1500 (BYTES) 


^ 


^ 


INSPEED: 1200000 OUTSPEED: 1200000 


^ 


^ 


MISCARRAY: 


RECEIVE TIMEOUT: 20 SECS. 


^ 


^ 




LOCAL TIMEOUT: 60 SECS. 


^ 


* 




CONNECT TIMEOUT: 900 SECS. 


^ 


^ 




RESPONSE TIMEOUT: HSECS. 


^ 


^ 




LINE BID TIMEOUT: 60 SECS. 


^ 


^ 




NO. ERROR RETRIES: 


^ 


^ 




CLEAR-TO-SEND DELAY: 00.0 SECS. 


^ 


^ 




DATA-SET-READY DELAY: DISABLED. 


^ 


^ 




TRANSMISSION MODE: DUPLEX 


^ 


^ 




MMSTAT TRACE FACILITY: DISABLED 


^ 


^ 


DRIVERNAME: 


lOLANO 


^ 


^ 


DOWNLOAD FILE: csdlanl . pub. sys 


^ 


^ 


CTRACEINFO: 


ENTRIES=24 MASK=01 1 1 1 1000 


* 


^ 




TYPE OF TRACE = ALL, NOWRAP 


^ 


^ 


PHONELIST: 


ENTRIES=0 INDEX=0 


^ 


¥; 


IDLIST: 


ENTRIES=0 INDEX=0 


^ 


^ 


ERRORCODE: 


RECOVERABLE=0 IRRECOVERABLE=0 


^ 


^ 


MSGSENT: 1 


MS6RECV: 1 


^ 


* 


RECOVERRORS 


: IRRECOVERRORS: 


^ 



Figure 6-2. Begin Tracing and Line Information Messages 
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The opening Line Information Display box contains detailed information on how 
the line was opened, how the communications controller was configured 
(transmission speeds, timeout values, logical device number, etc.) and trace 
parameters selected. In the example in Figure 6-2, we know that: 

• the communications controller is an LANIC, because DEV. TYPE (device 
type) is 17 and DRIVERNAME is lOLANO, 

• it is a synchronous, switched line (i.e., dial-up), because it is SUBTYPE 9, 

• BUFFSIZE is 1 500 WORDS, so the configured line buffer size is 4095, 

• INSPEED and OUTSPEED (transmission speeds) are 1200000 characters per 
second. 

• MASK is 01 11 1 1 000 (%37; for LANIC ignores the three zeroes on the right), 

• ENTRIES=24 is the maximum number of entries in each trace record. (24 is 
the default.) 

• ALL events will be traced 

• Overflow record entries will be discarded (NOWRAP). 



Trace Record and Header Message 



The trace listing is organized into a series of trace records, each consisting of a 
series of trace entries. Every trace record pertains to a particular request. 

A trace record is signified by a header message. The header message identifies 
the CS intrinsic call that generated the trace record. The header (see the example 
in Figure 6-3) shows the name of the CS intrinsic, where the intrinsic was called 
from the program, the calling parameters and a REQUEST ID that is the same as 
the REQUEST ID for the corresponding record entries. 



^ iiiil REQUEST ID=%044347(!48E7) ^ 

^ g^[[|p. sEGMENT=PRG %000 ADDRESS=%000276 ^ 

* STATE: LINE STATE=DISCONNECT C0PTI0NS=%004201 D0PTI0NS=%002000 ^ 

^ INPUT: IN BUF=%000000 LENGTH=0 SPEC. STATION #=0 COMP #=0 ^ 

^ OUTPUT: TRANSMISSION LOG=0 RESP. STATION #=0 COMP #=0 ^ 

Figure 6-3. Trace Record Header 
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Trace Entry Format 

All entries in a trace listing contain a prefix consisting of four fields: 

1. An entry number (0 in the example in Figure 6-4). 

2. A "time stamp" in seconds and thousandths of seconds (17. 073 in the 
example). 

3. An entry-type mnemonic (PCMP in the example). Mnemonics are described 
later in this chapter. 

4. A "request ID" that correlates the entry with a particular intrinsic call 
(%043136 in Figure 6-4). 

The first entry is numbered zero, and successive entries throughout the rest of 
this trace record are numbered consecutively in ascending order (1, 2, 3 and so 
on). The "time stamp" makes it possible for you to determine the elapsed time 
between one trace entry and another. The mnemonic tells you what type of 
trace entry you are examining. There are five types of trace entries used in 
Network Services. They are summarized in Table 6-2 and described in greater 
detail on the following pages. The body of each trace entry tells you the 
pertinent information for the particular activity that has happened or is about to 
happen. 



17.073 PCMP REQUEST ID=%043136(!465E) 

ERROR CODE=0 LAST RECOVERABLE ERROR CODE= 
FUNC C0DE=7 LAST FATAL ERROR CODE= 

#MSG SENT=1 #MSG RECV=1 STATE=CONNECTED 
# RECOVERABLE ERR=0 # IRRECOVERABLE ERR=0 

Figure 6-4. Sample Trace Entry 
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Missing Entries Message 



If MISSING ENTRIES appears in the listing, it means that the record was not 
large enough to accommodate all of the trace entries and some entries were lost. 
If WRAP was not specified (NOWRAP), then the missing entries were at the end just 
before the PCMP entry; otherwise they are missing from the beginning where 
they were overlaid by the trace entries that extended past the end of the record. 
If the missing entries are crucial: 

1, Purge the trace file. 

2. Invoke trace again, issuing : LINKCONTROL with 

a. a larger numentries value 

b. a mask setting that will produce only those trace entries you are really 
interested in. 



Trace Entry Mnemonics 



There are five types of trace entries created by the LANIC driver. There are no 
conflicts with NMS tracing. A received frame will generate the following 
sequence of entries which are summarized in Table 6-2 and described in greater 
detail on the pages following this table. 
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Table 6-2. Trace Entry Type Mnemonics 



Mnemonic 


Entry Type 


Definition 


PRCT 


Receive 
Control 
Sequence 


Generated each time a control character sequence is 
received from the remote station. The PRCT trace 
entry shows (in octal or hexadecimal) the exact 
sequence of bytes that v^as received. 


PSCT 


Send 

Control 

Sequence 


Generated each time the driver sends a control 
character sequence to the remote station. The PSCT 
trace entry shows (in octal or hexadecimal) the 
exact sequence of bytes that was sent. 


PRTX 


Receive 
Text 


Generated each time a message is received from a 
remote station. The PRTX trace entry shows (in 
octal or hexadecimal) the exact sequence of bytes 
received. 


PSTX 


Send 
Text 


Generated each time the driver sends a message to 
the remote station. The PSTX entry shows (in octal 
or hexadecimal) the exact sequence of bytes sent. 
There is one PRCT entry for every frame received. 


PCMP 


User 

Request 

Completed 


Generated each time an I/O operation to the 
LANIC occurs. The PCMP trace entry summarizes 
the line activity, such as the number of frames sent 
and received and the number of errors that have 
occurred. 
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PSCT (PRCT) Trace Entries 



The PSCT (PRCT), meaning "Sent (Received) Control", is really the first part of a 
text block. The way it works is that there is one PSCT (PRCT) entry and zero or 
more PSTX (PRTX), meaning "Sent (Received) Text" entries for every 
transmission (received) frame traced. The PSCT (PRCT) entry will contain the 
first 32 bytes of sent/received frame, and the remaining bytes will be included in 
subsequent PSTX (PRTX) entries. 

The first 32 bytes of a sent (received) LANIC frame will a contain a header. An 
example is shown in Figure 6-5. 



59.274 PRCT REQUEST ID=%043622(!4792) 

MUI P/F=0 DEST=0800 0900 0821 DSAP=18 

SRC=0800 0900 1808 SSAP=18 C/R=0 
FLOW ID=420 07D2 F40D 



The header data will also be included, unformatted, in the raw data: 



8.0 9.0 8.2 1 8.0 9.0 I 8.0 9 

BS NULHT NULBS ! BS NUL HT NUL CAN HT 

1 8.1 8 4.2 7.D 2 F 4.0 D 3.8 5 8.0 

CAN CAN EOT BEL R | CR ETX ENQ BS NUL 

9.0 1 8.0 9 0.2 B 1 8.1 8 

HT NUL CAN HT NUL + CANCAN 

Figure 6-5. PRCT Trace Entry 
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The meaning of the various items are as follows: 
MUI 



P/F 

DEST 

DSAP 

SRC 
SSAP 

C/R 
FLOW ID 



Mode-independent Unnumbered Information (frame type), 
other options are XID (exchange Identity), TEST (test), and !xx 
(undecodable). 

Poll/Final bit (0 or 1). 

This the destination address. 

Destination Service Access Point points to the proper protocol 
the next higher level. 

This is the source address. 

Source Service Access Point points from the proper protocol 
of the next higher level. 

Command = and Response = 1. 

This is a unique 48-bit quantity that is not used presently. 



Note that, in order to facilitate tracing, the format of the 32 byte header does 
not coincide with the data actually sent or received on the wire. The LANIC 
driver header contains data that allows the dump reader to match the link-level 
trace entries with higher level trace entries. The formats are provided on the 
next page. 



Tracing 
6-15 



PRCT formot 



PSCT formot (0) 



PSCT formot (1) 



byte 


5 
6 

1 1 
12 

U 
14 



19 
20 

21 



31 



destinotion 
address 



source 
oddress 



dest SAP 



source SAP 



flow ID to 
match w/hi- 
level trace 



control 



undefined 



byte 


5 
6 

1 1 
12 

13 
14 



19 
20 



26 
27 
28 
29 
30 
31 



destinotion 
address 



flow ID to 
match w/hi- 
level troce 



undefined 



destinotion 
address 



source 
address 



length 



dest SAP 



source SAP 



control 



undefined 



byte 


5 
6 

1 1 
12 

13 

14 
15 

16 



Figure 6-6. PRCF and PSCT Formats 



21 
22 

27 
28 
29 
30 
31 



destination 
address 



flow ID to 
match w/hi- 
level trace 



undefined 



destination 
address 



source 
address 



length 



dest SAP 



source SAP 
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The difference in format between the two PSCT entries is whether the user data 
started on an even byte [PSCT(O)] or an odd byte [PSCT(l)]. Now, in the case of 
PSCT format (even-byte user data), the data field will begin the first byte (i.e., 
byte 0) of the PSTX entry immediately following the PSCT entry. The data 
actually transmitted onto the AUI (and therefore onto the coaxial cable) begins 
at byte 14, and byte 31 will be discarded before transmission. 

For the PSCT format 1 (odd-byte user data) and the PRCT entries, the first 
PSTX/PRTX entries will contain a garbage byte (this will actually contain the 
control field). In this case, the data actually transmitted on to the AUI (and 
therefore onto the coaxial cable) begins at byte 16, and all bytes will be 
transmitted (no bytes are discarded before transmission). 



NOTE 



It is important to recognize that this byte exists in all received packets and in 
some transmit packets if the trace output is to be understood correctly. 



PCMP Trace Entries 



A PCMP trace entry is generated each time an I/O request is completed. An 
example is shown in Figure 6-6. 



72.717 PCMP REQUEST ID=%043533( ! 475B) 

ERROR CODE=0 LAST RECOVERABLE ERROR CODE= 

FUNC CODE= LAST FATAL ERROR CODE= 

mSG SENT=2 #NSG RECV=2 STATE=CONNECTED 

# RECOVERABLE ERR=1 # IRRECOVERABLE ERR=0 



Figure 6-7. PCMP Trace Entry 
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The meanings of the various items are as follows: 
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ERROR CODE: 



The code of the request's most recent Recoverable 
Error or Irrecoverable Error (see the CS trace section 
of the Fundamental Data Commimications Handbook 
for CS error codes). 



FUNG CODE: 



This describes the nature of the operation whose 
completion is being traced by the PCMP trace entry 
(refer to table 6-3). 



# MSG SENT: 



The total number of text messages sent so far for this 
connection. 



# MSG REGV: 



The total number of text messages received so far for 
this connection. 



STATE: 



The line state after the completion of the user 
request. In the example it is in the connected state. 



§ RECOVERABLE ERR: 



The total number of Recoverable Errors that have 
occurred so far for this connection. 



# IRRECOVERABLE ERR: The total number of Irrecoverable Errors that have 

occurred so far for this connection. Note the Last 
Fatal Error Code is the Last Irrecoverable Error Code. 



Table 6-3. Function Codes 



FUNC CODE 


FUNCTION 





READ 


1 


WRITE 


5 


CONTROL 


7 


INFO TRANSFER 


9 


HARD ABORT 


66 


ABORT 10 



End of Trace and Line Information Messages 



The END OF TRACE .... message appears in the listing when the trace is turned 
off. The message tells you the decimal logical number of the line (36 in the 
example in Figure 6-7) and indicates that the line's activities are no longer being 
monitored by the trace facility. It is followed by the Line Information Display, 
showing the state of the line just before tracing was stopped. Note the counts of 
messages sent (1 in our example), messages received (1 in our example), number 
of recoverable errors (4 in our example), and number of irrecoverable errors (0 
in our example). 

* END OF TRACE FOR DEVICE 36 * 
^-L-I-N-E---I-N-F-0-R-M-A-T-I-0-N---D-I-S-P-L-A-Y^ 



LINE NUMBER: 4 
DEV. TYPE: 17 



COPTIONS 

AOPTIONS 

DOPTIONS 

NETWORK'ID 

NUMBUFFERS 



LOGICAL DEV. 
SUBTYPE: 3 
0123456789012345 
0000100010000010 
0000000100001101 
0000010000000000 
0000000000000000 
1 BUFFSIZE: 
INSPEED: 1200000 OUTSPEED: 
MISCARRAY: RECEIVE TIMEOUT: 

LOCAL TIMEOUT: 

CONNECT TIMEOUT: 

RESPONSE TIMEOUT: 

LINE BID TIMEOUT: 

NO. ERROR RETRIES: 

CLEAR-TO-SEND DELAY: 

DATA-SET-READY DELAY: 

TRANSMISSION MODE: 

MMSTAT TRACE FACILITY: 

DRIVERNAME: lOLANO 

DOWNLOAD FILE: csdlanl . pub. sys 



NUMBER: 36 ^ 
VER: X.55.23 ^ 



1500 (BYTES) ^ 



1200000 



SECS. 
SECS. 
SECS. 
HSECS. 
SECS. 



20 

60 

900 



60 



00.0 SECS. 

DISABLED. 

DUPLEX. 

DISABLED. 



CTRACEINFO: 



ENTRIES=24 



MASK=0111 11000 



TYPE OF TRACE = ALL, NOWRAP 



PHONELIST: 
IDLIST: 
ERRORCODE: 
MSGSENT: 1 
RECOVERRORS: 



ENTRIES=0 
ENTRIES=0 
RECOVERABLE=0 



INDEX=0 

INDEX=0 
IRRECOVERABLE=0 
MSGRECV: 1 
IRRECOVERRORS: 



END OF JOB. 

Figure 6-8. End of Trace and Closing Line Information 
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CS Error Codes 



Table 6-4. Code Meaning of Irrecoverable Errors 



Code 

(Decimal) 


Meaning 





No error. 


13 


Text overflow (> 1500 bytes of user data). 


52 


Invalid operator. 


63 


No I/O found to abort. 


64 


Abort ignored because I/O already completed or aborted. 


116 


Software timeout. 


117 


Invalid interrupt. 


120 


Driver internal error. 


121 


Self test failure. 


130 


System fail, LANIC. 


131 


Power failure. 


133 


TRANSMIT: Transmit incomplete in absence of abnormal 
condition. 


134 


Fatal MAU power error. 


135 


MAU jabber error occurred. 


153 


Duplicate address. 


160 


An internal error detected by MPE. 


201 


Operation aborted. 


223 


RECEIVE: buffer space, ran out. 
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Code 

(Decimal) 







3 
16 

17 
121 
134 



135 



137 



138 



139 



207 



Table 6-5. Code Meaning of Recovered Errors 



Meaning 



No error. 



RECEIVE: frame too short, length field error, unintelligible 
sequence received. 



RECEIVE: PCS error (CRC). 



RECEIVE: overrun (DMA). 



TRANSMIT: underrun. 



Self test failure. 



MAU power, recovered. 



MAU jabber, recovered. 



136 TRANSMIT: CRS on always, SQE not on always, DI not on 

always. 



TRANSMIT: DI never idle, SQE not on always. 



TRANSMIT: SQE on always, DI not on always. 



TRANSMIT: SQE on always, DI never idle. 



Excessive collisions. 
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Memory Dump 



When a SYSFAIL or some other severe condition occurs, refer to the MPE V 
System Operation and Resource Management Reference Manual (32033-90005) 
for instructions on doing a memory dump. 



NSDPAN5/NSDUMPJ 



The NSDPAN5 program produces a formatted listing of main memory, based on 
a memory dump taken after a system failure, HALT, or other abnormal 
condition. 



Obtaining an NSDPAN5 Listing 



1. Immediately after system termination, use the Software Dump Facility 
(SDF) to make a main memory dump. This facility gives you the capability 
of storing main memory to either a serial disc, cartridge tape, or magnetic 
tape. It operates in a stand-alone environment after a system failure has 
occurred or a system halt has been performed. The SDF is described in the 
MPE V System Operation and Resource Management Reference Manual 
(32033-90005). 

2. When the system has been restarted, enter the command: 
i STREAM NSDUMPJ.NET, SYS - 

This version of NSDPAN5 has several advantages: 

• It is customized to show NS data structures. 

• It saves virtual memory 

• If the problem is in another product, this dump still applies. 
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LISTL0G5 



LISTL0G5 analyzes files in the MPE system log file. An MPE log file records 
events such as session or job initiation and termination, process termination, file 
closure, I/O errors, and system shutdown. Refer to the MPE V System Operation 
and Resource Management Reference Manual (32033-90005) for more 
information on system logging. 



NOTE 



Refer to NS3000/V Network Manager Reference Manual (32344-90002) for 
information on NMDUMP and NMS logging. 



System manager (SM) capability is needed to run LISTL0G5. 

Log files are named by the following convention, where nnnn is a four-digit 
number: 

LOGww.PUB.SYS 

The formal file designator of the output file is LOGLIST, with the default device 
class LP. LOGLIST is opened as new, and closed as a permanent file. 



Operation of LrSTLOGS 



1. To find out which log files are on the system before you run LISTLOG5, 
enter the following: 

i LISTF LOG@.PUB.SYS 

MPE returns a list of filenames numbers for all of the log files currently on 
the system. These are the valid logfile numbers you can choose from when 
you run LISTL0G5. For example: 



FILENAME 



LOG 

LOG 1970 
L0G1976 



L0G1971 
L0G1977 



L0G1972 
L0G1978 



L0G1973 
L0G1979 



L0G1974 
L0G1980 



L0G1975 
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2. To run LISTL0G5, type: 
: RUN LISTL0G5.PUB.SYS 

3. LISTL0G5 identifies itself and asks for the number of the first 
log file to print: 

LISTL0G5 G.00.00 (C) HEWLETT-PACKARD CO., 1982 

ENTER FIRST AND LAST LOG FILES TO BE ANALYZED 
FIRST? 1973 

Enter the four-digit numbers from the list of log files. If 
you only want to analyze one file, enter it as the first file 
number and press [RETURN) in response to the "LAST?" 
prompt. 

4. You are then prompted for the four-digit number of the last log file to 
print. Press [RETURN! to list only the first file. 

LAST? 1980 

5. LISTL0G5 now displays a numbered list of events for which 
histories can be printed: 



TYPE NO. 


EVENT 





LOG FAILURE 


1 


SYSTEM UP 


2 


JOB INITIATION 


3 


JOB TERMINATION 


4 


PROCESS TERMINATION 


5 


FILE CLOSE 


6 


SYSTEM SHUTDOWN 


7 


POWER FAILURE 


8 


SPOOLING LOG RECORD 


9 


LINE DISCONNECTION 


10 


LINE CLOSE 


11 


I/O ERRORS 


12 


PRIVATE VOLUMES 


13 


PRIVATE VOLUMES 


14 


TAPE LABELS 


15 


CONSOLE LOG RECORDS 


16 


PROGRAM FILE EVENT 


17 


DOE PROVIDED INFO 


18 


MAINTENANCE REQUEST 


19 


DIAGNOSTIC CONTROL UNIT 
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At the end of the list of events, you are prompted for input with the 
message: 

ENTER EVENT NUMBERS SEPARATED BY COMMAS? 

A CARRIAGE RETURN ASSUMES ALL EVENTS WILL BE EVALUATED. 



Type the event numbers and press [RETURNI . LISTLOG5 creates spool files of 
the events that you requested. There are no messages echoed back to your 
terminal if your request is successful. If you request is not successful, one of 
two messages will be displayed: 1) an error message in the format described 
under "ERROR CONDITIONS", or 2) a message indicating that there are no 
events for the log file numbers that you requested: 

NO DESIRED EVENTS FOUND IN LOGFILE 1980 

If events have been found for a log file, it's number will not appear in the 
NO DESIRED EVENTS list: 

NO DESIRED EVENTS FOUND IN LOGFILE 1978 
NO DESIRED EVENTS FOUND IN LOGFILE 1979 

Events have been found for all other requested log files, so they do not 
appear in this list. 

LISTL0G5 then asks: 

DO YOU WANT TO PURGE LOG FILES? 

If you answer YES, then log files are printed and then purged from the 
system. If you answer NO, the files are printed and also retained by the 
system. You are now asked if you want to return to the program; Type 
YES to continue with L0GLIST5, NO or N to terminate: 

DO YOU WISH TO RUN AGAIN (Y OR N)? N 
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NMMAINT 



The NM Maintenance Utility (NMMAINT) is a utility program supplied with HP 
3000 LAN link products as part of the Node Management Services (NMS). 
NMMAINT is used to display the individual and overall version numbers for the 
software modules of the data communications products that use the Node 
Management Services (NMS). These products include the NS3000/Y, SNA IMF, 
and SNA NRJE Network Services products as well as the SNA and LAN3000/V 
Network Link products. 

NMS defines one or more subsystems for each of the data communications 
products. For the HP3000 LAN link, there are three subsystems defined: the 
Node Management Services, the Network Transport, and the Link Services 
subsystems. For NS3000/V, there is one subsystem, the Network Services. Each 
software module within a subsystem, such as a program file or SL segment, has 
its own version ID number. If the version, update, and fix levels of these 
modules do not match, the subsystem will not work correctly. NMMAINT can 
be used to determine if you have an invalid software installation or if the 
software modules of a subsystem are mismatched. The information provided by 
NMMAINT should be included in any SR submitted. Refer to the NS3000/V 
Network Manager Reference Manual. 

To run NMMAINT, issue the command: 

: RUN NMMAINT, PUB. SYS 

NMMAINT will respond with the following: 

32099-11018A.01 .00 NM Maintenance Utility (C) Hewlett Packard 
Co. 1985 

NMMAINT then lists the version identification numbers for each software 
module as well as subsystem information for each subsystem. As shown in the 
example below, the NMMAINT utility displays version information for the 
subsystems of the products actually installed on your system. The Node 
Management Services, Link Services, and Network Transport subsystems are 
displayed if the HP 3000 LAN link product is installed. The Network Services 
subsystem is displayed if the NS3000/V product is installed. The SNA Transport, 
NRJE, and IMF subsystems are displayed if the appropriate HP to IBM data 
communications products are installed on your system. The example shows a 
system with NS3000/V and the HP 3000 LAN link installed. The subsystems are 
always displayed in the same order, which is the Node Management Services 
subsystem first, followed by SNA Transport, NRJE, and IMF, then the Network 
Transport, Network Services, and Link Services subsystems. The last version ID 
number listed is the port software, IPCVERSION. This is not part of the 
NetworklPC user service, nor does it form a subsystem as the previous sets, but 
its individual version ID number is displayed by NMMAINT for your 
information. 
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Example 



As described, version ID numbers include version, update, and fix levels as well as 
an internal fix level in the format Vuuffiii, In the example below, where 
NMVERSOO is listed, its version ID number is A01 00016. The A is the version 
level, the next two zeros represent the update level, and the following two zeros 
are the fix level. The remaining numbers, 016, show the internal fix level, which 
is used only within Hewlett-Packard. 



The following example shows the information displayed when you use the 
NMMAINT utility. A discussion follows the example. 



: RUN NMMAINT.PUB,SYS 

32099-1 1018A. 01 .00 NM Maintenance Utility (C) Hewlett Packard Co. 1985 
Subsystem version ID's 



Node Management Services 32099-11018 module versions: 



SL procedure: 
SL procedure: 
SL procedure: 
SL procedure: 
SL procedure: 
SL procedure: 
SL procedure: 
SL procedure: 
Program file: 
Program file: 
Program file: 
Program file: 
V+ forms file: 
Program file: 
Program file: 
Catalog file: 



NMVERSOO 

NMVERS01 

NMLOGSLVERS 

NMLOGDATAVERS 

NMVERS04 

NMVERS05 

NMVERS06 

MCVERS 

NMMAINT. PUB. SYS 

NMFILE.PUB.SYS 

NMLOGMON.PUB.SYS 

NMMGR.PUB.SYS 

NMMGRF.PUB.SYS 

NMMGRVER.PUB.SYS 

NMDUMP.PUB.SYS 

NMCAT.PUB.SYS 



Version: 
Version: 
Version: 
Version: 
Version : 
Version: 
Version: 
Version: 
Version: 
Version: 
Version: 
Version: 
Version: 
Version : 
Version : 
Version: 



A01 00000 
A01 00000 
A01 00000 
A01 00000 
A01 00000 
A0100000 
A01 00000 
A01 00000 
A01 00000 
A01 00000 
A01 00000 
A01 00000 
A01 00000 
A01 00000 
A01 00000 
A01 00000 



Node Management Services 32099-11018 overall version = A. 01. 00 



(Continued on Next Page) 
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Network Transport Module Versions 



Program File 
Program File 
Program File 
Program File 
Message File 
SL Procedure 
SL Procedure 
SL Procedure 
SL Procedure 
SL Procedure 
SL Procedure 
SL Procedure 
SL Procedure 
SL Procedure 
SL Procedure 
SL Procedure 
SL Procedure 
SL Procedure 
SL Procedure 
SL Procedure 
SL Procedure 
SL Procedure 



NETCP.NET. SYS 

NETSERVE.NET. SYS 

SOCKREG.NET. SYS 

NETMSG.NET. SYS 

NET'SM4'VERS 

NET'UI'VERS 

NET'SL'VERS 

NET'NI'VERS 

NET'PROBE'VERS 

NET'TCPO'VERS 

NET'TCPI 'VERS 

NET'PXPO'VERS 

NET'PXPI 'VERS 

NET'IP'VERS 

NET'IPU'VERS 

NET'PD'VERS 

SOCKIOVERS 

SOCKACCESSVERS 

S0CKMISC1VERS 

SUBSYS3FMTVERS 

SUBSYS5FMTVERS 

TRIGVERS 



Version: 
Version: 
Version: 
Version: 
Version: 
Version: 
Version: 
Version: 
Version: 
Version: 
Version: 
Version: 
Version: 
Version: 
Version: 
Version: 
Version: 
Version: 
Version : 
Version : 
Version : 
^^ Not I 



AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
nstalled 



Network Transport Overall Version : A. 00. 00 



Network Services HP32344 individual module versions 



SL procedure: 
SL procedure: 
SL procedure: 
SL procedure: 
SL procedure: 
SL procedure: 
SL procedure: 
SL procedure: 
SL procedure: 
SL procedure: 
Program file: 
Program file: 
Program file: 
Program file: 



ASCXVERS 

ASBUFVERS 

ASENVVERS 

DSUTILVERS 

ASRFAVERS 

VTSVERS1 

VTSVERS2 

ASPTOPVERS 

ASRPMVERS 

SUBSYS6FMTVERS 

DSDAD.NET. SYS 

DSSERVER.NET. SYS 

lOVTERMO.PUB.SYS 

NFT.NET. SYS 



Version 

Version 

Version 

Version 

Version 

Version 

Version 

Version 

Version 

Version: 

Version 

Version 

Version 

Version 



AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 
AOOOOOOO 



letwork Services HP32344 overall subsystem version: A. 00. 00 



Software Tools 

7-7 



LINK SERVICE Subsystems VERSION 



module versions 



SL procedure; 
SL procedure; 
SL procedure; 
SL procedure: 
SL procedure: 
SL procedure: 
Program file: 



IRAN 'VERSO 

TRAN'VERSI 

BFMICSVERS 

BFMVERS 

SUBSYS8FMTVERS 

LINKVERS 

LINKMGR.PUB.SYS 



LINK SERVICE Subsystems VERSION 
SL Procedure: IPCVERSION 



Version: 
Version: 
Version: 
Version: 
Version: 
Version: 
Version: 



B0206000 
B0206000 
B0206000 
B0206000 
B0206000 
B0206000 
B0206000 



overall version = B. 02.06 
Version: B0204000 



In the previous example, the first group of numbers listed are the version ID 
numbers of the modules of the Node Management Services subsystem, part of 
the HP 3000 LAN link. Notice that the first five characters of the version for 
each module listed in this group are A01 00. This means that all the software 
modules in the subsystem match. This must be true for all the modules of a 
given subsystem. If a subsystem module is invalid, the follov^ing error message is 
printed: 



Program file: NMMAINT. PUB.SYS ^^ MODULE ERROR ^^ 

ONE OR MORE SUBSYSTEM MODULES ARE INVALID. (NMERR 105) 

This message indicates that the modules of the subsystem are not compatible. 
Because the module version ID numbers match, NMMAINT displays the overall 
subsystem version number for NMS as A.OI.OO. The rest of the subsystems are 
handled in a similar fashion. 

NMMAINT also checks that all the modules that belong with a particular 
subsystem are present. If a module is missing, NMMAINT displays the name of 
the module with the following error message in place of the version number. 

SL procedure: NMVERS01 *^ REQ'D MODULE MISSING 

ONE OR MORE REQUIRED SUBSYSTEM MODULES ARE MISSING. (NMERR 104) 

If this is a new software installation, check your installation procedure. 

If the modules were correct when installed, only unusual circumstances, such as a 
reload, a disc problem, or a system failure, result in missing or invalid modules. 
Restore a known valid version of such modules. Refer to the NS3000/V 
Network Manager Reference Manual. 
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The missing module may be optional. For example: 



SL Procedure : TRIGVERS ^^Not installed 

This module, TRIGVERS, is not normally present on the system. It is only 
installed by an HP system engineer if needed for troubleshooting. 

Question marks in the overall version number indicate that the fix levels of the 
individual modules do not match. Remember that the internal fix level, 
represented by the last three numbers of the version ID, does not need to match 
between modules for the softv^are to be compatible; therefore it may be 
disregarded. The fix numbers are requested for Service Requests; it makes a 
considerable difference to HP when troubleshooting. 

As each subsystem is displayed, NMMAINT checks that all the modules are 
present and compatible with each other. However, NMMAINT does not 
perform any cross-subsystem version verification. When a system has HP to IBM 
products as well as HP to HP products installed, you need to be aware of the 
fact that the Node Management Services, the Link Services, and the port 
software are used by both types of data communications products. Therefore, it 
is important to check that the version numbers of these common subsystems and 
port software modules are correct. It is possible for the HP to IBM products to 
use previous versions of the common software that are not compatible with the 
HP to HP products. For more information, refer to the NS3000/V Network 
Manager Reference Manual. 

NMMAINT only displays information on the subsystems for the products that 
are installed on your system. Thus, the NMMAINT display from different 
systems may vary, depending on which products are installed on the system. In 
the example above, the SNA Link, SNA NRJE, and SNA IMF products were not 
installed, so the the SNA Transport, NRJE and IMF subsystems were not 
displayed. 
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CSLIST 



The Communications Systems (CS/3000) subsystem consists of the software 
modules used for link management and diagnostics. It is used by all HP data 
communications network link products, including the HP 3000 LAN link and the 
DS Compatible Links. The CSLIST utility lists the version numbers for the 
software modules of the CS subsystem. CSLIST also provides detailed 
information on the INP and LANIC download files on your system. The 
information provided by CSLIST must he included in any Service Request 
submitted to HP. Refer to the NS3000/V Network Manager Reference Manual. 

Example 1 shows how to run CSLIST. 



Example 1 



: RUN CSLIST. PUB. SYS 

HP30131A. 55.25 CSLIST/3000 SUN, MAR 17, 1984, 9;05 AM 
(C) HEWLETT-PACKARD CO. 1980 

THIS ROUTINE HAS TWO MAJOR FUNCTIONS - ONE ASSOCIATED WITH 
THE CS MODULES AND ONE ASSOCIATED WITH THE DOWNLOAD FILES. 

THE FIRST PORTION REPORTS THE CS MODULES INSTALLED 

ON THE SYSTEM. 

NOTINSTD INDICATES THE MODULE HAS NOT BEEN INSTALLED ON THE SYSTEM. 

CSLIST ALSO ALLOWS THE USER TO OBTAIN INFORMATION 
CONCERNING THE HP-STANDARD DOWNLOAD FILES. 
THIS INFORMATION INCLUDES PROTOCOL TYPE, BOARD TYPE, 
COMPILE DATE, AND VERSION NUMBER INFORMATION. 

DO YOU WANT A COMPLETE LISTING OF INSTALLED VUFS? YES 

DO YOU WANT THE DOWNLOAD FILE INFORMATION? NO 

SHOULD OUTPUT BE DIRECTED TO THE LP? YES 



After the the RUN command for CSLIST is issued, CSLIST displays a header and 
a description, followed by a series of prompts. In the first example, the user 

requested a complete listing of the CS module version numbers, without the 
download file information, and specified that the output should be directed to 
the lineprinter (device LP). 
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Example 2 shows a typical listing of CS modules produced by CSLIST. 



Example 2 



HP30131v.uu.ff CSLIST/3000 SUN, MAR 17, 1985, 9:05 AM 
(C) HEWLETT-PACKARD CO. 1980 

COMPLETE LISTING OF INSTALLED VUFS NOW BEING PRODUCED. 
OUTPUT GOING TO DEVICE LP. 



C0MSYS1 


INSTALLED 


VUF 


IS 


V. 


. uu, 


.ff 


C0MSYS2 


INSTALLED 


VUF 


IS 


V, 


. uu, 


.ff 


C0MSYS3 


INSTALLED 


VUF 


IS 


V , 


, uu, 


.ff 


C0MSYS4 


INSTALLED 


VUF 


IS 


V, 


, uu , 


.ff 


C0MSYS5 


INSTALLED 


VUF 


IS 


V, 


.uu. 


.ff 


CSUTILITY 


INSTALLED 


VUF 


IS 


V , 


, uu. 


.ff 


CSDUMMY 


INSTALLED 


VUF 


IS 


V, 


, uu. 


.ff 


CSDUMP 


INSTALLED 


VUF 


IS 


V , 


, uu. 


.ff 


TRACPROG 


INSTALLED 


VUF 


IS 


V. 


, uu. 


.ff 


lOINPO 


INSTALLED 


VUF 


IS 


V. 


, uu. 


.ff 


DSM 


INSTALLED 


VUF 


IS 


V. 


, uu , 


.ff 


INPDPAN 


INSTALLED 


VUF 


IS 


v. 


, uu . 


.ff 


NETCONF 


INSTALLED 


VUF 


IS 


V. 


. uu, 


.ff 


CSLIST 


INSTALLED 


VUF 


IS 


V. 


, uu, 


.ff 


lOLANO 


INSTALLED 


VUF 


IS 


V. 


, uu, 


.ff 


LANDPAN 


INSTALLED 


VUF 


IS 


V. 


. uu, 


.ff 


LANDIAG 


INSTALLED 


VUF 


IS 


V . 


. uu , 


.ff 



In the first example, the download file information was not selected. Since 
CSLIST lists information on all of the download files for all of the HP 3000 
products installed on your system, requesting the download file information may 
produce a lengthy listing. 

The alternative, recommended if you want to check a specific download file, is 
to use CSLIST with an entrypoint. The entrypoint, either LAN or IN P, is 
appended to the run command, as shown in Example 3 below. When you use 
CSLIST with an entrypoint, CSLIST displays an abbreviated description and 
prompts for the download file for which you need information. 
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Example 3 

; RUN CSLIST.PUB.SYS.LAN 

CSLIST ALLOWS THE USER TO OBTAIN INFORMATION 
CONCERNING USER-SPECIFIED DOWNLOAD FILES. THIS 
INFORMATION INCLUDES PROTOCOL TYPE, BOARD TYPE, 
COMPILE DATE, AND VERSION NUMBER INFORMATION. 

SHOULD OUTPUT BE DIRECTED TO THE LP? 

DOWNLOAD FILE NAME = CSDLAN1 . PUB.SYS 

LAN DOWNLOAD FILE = CSDLAN1 . PUB.SYS 
LAST MODIFIED WED, NOV 21, 1984, 9:41 AM 
DRIVER OPTIONS = %000000 
DATE CODE = B. 00. 014. 077 

DOWNLOAD FILE NAME = CSDLAPB2. PUB. SYS 

DOWNLOADFILE= CSDLAPB2. PUB.SYS PROTOCOL TYPE= X.25 

BOARD TYPE= INP 20B COMPILE DATE= WED, JUL 4, 1984, 6:26 PM 

IC VERSION = 01.02 
PROTOCOL VERSION = 01.04 

TRACE VERSION = 02.06 

RAMCP VERSION = 05.04 

DOWNLOAD FILE NAME = CSDBSC2. PUB.SYS 

DOWNLOADFILE= CSDBSC2. PUB.SYS PROTOCOL TYPE= BISYNC (DS,RJE,X.21 ) 

BOARD TYPE= INP 20B COMPILE DATE= THU, OCT 25, 1984, 1:56 PM 

IC VERSION = 01.02 
PROTOCOL VERSION =01.11 

TRACE VERSION = 02.06 

RAMCP VERSION = 05.05 

DOWNLOAD FILE NAME = 
END OF PROGRAM 

The download files specified in Example 3 were for a LAN link (LANIC), a 
Point-to-Point Link (JNP), and an XJ25 Link (INP). Notice that CSLIST provided 
information on all three download files, even though two are for the INP. 
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DSLIST 



For the modules of the DS Services subsystem of NS3000/V, and for any of the 
DS Compatible Links installed on your system, use the DSLIST program installed 
in the PUB group of the SYS account to obtain a list of the versions of the 
software modules. 

In the DSLIST display, shown in the example below, notice that most of the 
modules are grouped under a product number heading. There is also a common 
module heading for the utilities, including this one, that apply to all the DS 
compatible links. 

All modules shown, except those for DSN/X.25, should be displayed on your 
system The DSN/DS HP32189B modules are used by the Point-to-Point Links 
and by the DS Services subsystem of NS3000/V. The DSN/X.25 HP32191B 
modules are installed with the X.25 Network Link; they only appear if an X.25 
Link is installed on your system. The CS HP30131A modules show a subset of 
the display provided by CSLIST. The COMSYS module is an overall version 
number for the CS modules. The NETCONF module is the utility used for the 
network configuration of the X.25 Network Link, described in the DSN/X.25 
for the HP 3000 Reference Manual. 

It is essential that: 

- all the DS software modules installed on the system have the same version 
identification; 

- all the X.25 software modules (if installed) have the same version; and, 

- all the common and CS modules have the same version 

in order to ensure successful operation. The information provided by DSLIST 
should be included in any SR submitted. Refer to the NS3000/V Network 
Manager Reference Manual. 
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Example 



:RUN DSLIST.PUB.SYS 



HEWLETT PACKARD 32189v.uu.ff DSLIST/3000 SUN, MAR 17, 1985, 7:07 PM 
DSN/DS HP32189B: 



MODULE 


VERSION 








SL DSSEGS 


v.uu.ff , 


INTERNAL 


FIX 


XXX 


SL DSRTECALL 


v.uu.ff , 


INTERNAL 


FIX 


XXX 


DSMON 


v.uu.ff. 


INTERNAL 


FIX 


XXX 


DSTEST 


v.uu.ff. 


INTERNAL 


FIX 


XXX 


DS2026 


v.uu.ff. 


INTERNAL 


FIX 


XXX 


DS2026CN 


v.uu.ff. 


INTERNAL 


FIX 


XXX 


DSCOPY 


v.uu.ff, 


INTERNAL 


FIX 


XXX 


lODSO 


v.uu.ff. 


INTERNAL 


FIX 


XXX 


lODSTRMO 


v.uu.ff. 


INTERNAL 


FIX 


XXX 


lODSTRMX 


v.uu.ff. 


INTERNAL 


FIX 


XXX 


DSN/X.25 HP32191B: 








MODULE 


VERSION 








DSMONX 


v.uu.ff. 


INTERNAL 


FIX 


XXX 


lODSX 


v.uu.ff, 


INTERNAL 


FIX 


XXX 


lOPADO 


v.uu.ff. 


INTERNAL 


FIX 


XXX 


I0PAD1 


v.uu.ff. 


INTERNAL 


FIX 


XXX 


COMMON MODULES: 








MODULE 


VERSION 








SL DSIOM 


v.uu.ff, 


INTERNAL 


FIX 


XXX 


DSDUMP 


v.uu.ff. 


INTERNAL 


FIX 


XXX 


DSLIST 


v.uu.ff. 


INTERNAL 


FIX 


XXX 



CS SUBSYSTEM HP30131A: 

MODULE VERSION 
SL COMSYS v.uu.ff, INTERNAL FIX xxx 

NETCONF v.uu.ff, INTERNAL FIX xxx 

END OF PROGRAM 



In the example, both Point-to-Point and X.25 Network Links were installed on 
the system. If X.25 was not installed, the DSLIST program would display a 
message "NOT INSTALLED" under the DSN/X.25 HP32191B heading, and the CS 
module NETCONF would not be displayed. 
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Troubleshooting Flowcharts 



Introduction 



This appendix suggests some procedures, in flowchart format, for use in 
troubleshooting your IEEE 802.3 LAN link. These procedures can help you find 
a faulty field replaceable unit (FRU). 

A LAN comprised of HP 3000 MPE-V based nodes is presumed. For a more 
general IEEE 802.3 LAN troubleshooting approach, refer to the LAN Link 
Hardware Troubleshooting Manual (Coaxial Cable LANs), 5955-7681 (HP CE 
Handbook version 5959-2217), or the HP Star LAN Diagnostics and 
Troubleshooting Manual for PCs, 50906-90060. 

Figure A-1 is an overview of the procedures, followed by the following: 



• the troubleshooting flowcharts, 

• supplemental Remote Note Testing information, and 

• Use of "Software Line Tests". 

The troubleshooting procedures can be modified as the conditions require. 
Experienced users may wish to alter the sequence (or actual implementation) of 
each procedure, especially for obvious faults. However, because each path in the 
procedures depends on previous outcomes, deviating from the procedures may 
cause troubleshooting errors that can be misleading. 



NOTE 



Recall that the LAN Node Diagnostic (LANDIAG) Test 16, Hood Loopback 
Test, does not apply to HP StarLAN connections. For StarLAN connections, 
refer to LANDIAG Test 14 (see Chapter 4). 
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Record SHOWCOM 

statistics. {Refer 

to Chapter 2.) 



Run LAN Node 
Diagnostics. 
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Remote 

Node. 
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Fix error. 
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Hardware 



Run Remote Node 

Tests: find 
LAN cable faults. 
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Connector; 

Find Node Faults. 





Yes 



Verify test 

components 

are good. 



Figure A-1. Hardware Troubleshooting Overview 
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LAN Node Diagnostic Flowcharts 



The troubleshooting flowcharts are presented on the following pages. Start with 
Flowchart 1. 
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Flowchart 1 

The first task involves determining if the configuration table and hardware 
match. For example, there is a possibility that the I/O configuration table for the 
LANIC card may have been entered v^rong or the wrong LDEV was specified. 

Refer to Chapter 4 for details on running the LAN Node diagnostic. 

On successful completion of this flowchart, you should be confident that the 
host has confirmed a responding channel exists at the specified LDEV, and that 
it is a LANIC card. Refer to the NS3000/V Network Manager Reference 
Manual for information about verification of Network (NMMGR) 
configuration. 
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of I/O Configuration 

Table. 



Run LAN Node 

Diagnostic. 
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of same priority. 



Yes 



Replace 
the LANIC. 



Flowchart 1. Verification of System and Hardware Configuration 
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Flowchart 2 

Flowchart 2 determines whether or not the LANIC card can be initialized, and 
verifies that most of the LANIC card is operating properly. The LANIC card 
self test is used. For more information on self test, refer to Chapter 5. 

A selftest failure does NOT always imply a faulty LANIC card. For successful 
selftest completion, the card must be connected to the LAN, or loopback 
connector. 

If Flowchart 2 yields no faults, you can be confident that the LANIC card can 
be initialized, and the microprocessor and LAN connection appear to operate 
properly. 
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Replace the LANIC; 

then rerun the 

Diagnostic. 



Yes 




Connect LANIC 
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Self Test 
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No 
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Diagnostic. 
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Flowchart 2. LANIC Initialization and Main Module Verification 
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Flowchart 3 

Flowchart 3 verifies operation of the LANIC card to SIMB/IMB interface. A 
subtle dependency exists between system operation and test execution. Refer to 
detailed descriptions of LANDIAG Tests 9 and 10 if these tests fail (see Chapter 
4). 

If Flowchart 3 successfully passes, the following are true: 

- the HP 3000 can communicate with the LANIC, 

- the LANIC card responds as expected, and 

- the LANIC can correctly access system memory for DMA processes. 
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Jest pass, 

J 
Yes 



Replace the LANIC 

then rerun the 

diagnostic. 





Yes 



Yes 



Return the diagnostic 

when the system 

is not busy. 



Yes 
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Replace the LANIC 

then rerun the 

diagnostic. 



Flowchart 3. Interrupt, Soft Reset, and SIMB/IMB Interface Verification 
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Flowchart 4 

In Flowchart 4, LANDIAG evaluates that portion of the node directly related to 
communications on the LAN. Specifically, the LAN coprocessor, card^-to-LAN 
interface, and LAN attachment hardware are exercised. 

Other LAN features tested during self test include: 

i. multicast addressing 

2. CRC generation/detection 

3. MAU/ThinMAU jabber protection (coaxial cable connections only) 

4. SQE disable operation (coaxial cable connections only) 

5. heartbeat detection (coaxial cable connections only) 

If Flowcharts 1 through 4 pass with no faults indicated, the node hardware is 
presumed good. 

However, marginal hardware faults may still exist, especially for coaxial LAN 
connections. These include MAU/ThinMAU faults that are difficult to detect 
by simply by bouncing test frames off the LAN cable. 

Marginal faults generally result in network performance degradation. For 
example, slight collision detect circuitry faults may cause frame check sequence 
(FCS) errors, Or, a weak MAU/ThinMAU transmitter or receiver may result in 
frames not being received by the intended node. 

The remaining flowcharts (Flowcharts 5 through 9) are intended to help find 
marginal faults on coaxial cable LAN connections. 
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Replace the LANIC. 




Yes 



Yes 



Use Test 14 and 

Loopback connector 

to find Node Fault. 
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Replace with 
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Yes 



Perform 
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Flowchart 4. LAN Coprocessor, Loopback and Date Code Verification 
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Flowchart 5 



NOTE 



Flowcharts 5 through 9 employ LANDIAG Test #16 and apply to coaxial cable 
LAN connections only. 



Flowchart 5 implements LANDIAG Test #16 to directly or indirectly check the 
following hardware: 

1. LANICcard, 

2. LANIC card cable (internal AUI for Series 39/4X/5X/6X/70 systems), 

3. AUI cabling, 

4. MAU/ThinMAU, 

5. Coaxial cable and associated hardware (Tap/BNC Tee connectors, barrels, 
connectors, terminators, etc.). 

For running Test 16, use of a known good loopback hood and MAU/ThinMAU 
is required. A loopback hood and MAU/ThinMAU can be verified as known 
good by testing them on a good node. Refer to Chapter 4 for the use of Test 16. 

Flowchart 5 checks for "MAU power-on" errors arising from Test 16, and directs 
the user to the next flowchart, as appropriate. 
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Flowchart 5. Identifying Failed FRU in Hood Loopback Test 
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Flowchart 6 

If MAU/ThinMAU power-on errors occur, or power-on attempts are excessive 
(more than 5), the following hardware may be faulty: 

1. LANIC card 

2. Internal cable short circuits (Series 39/4X/5X/6X/70 systems only), 

3. AUI cable short circuits, 

4. MAU/ThinMAU. 

Flowchart 5 provides steps to identify faulty hardware. 
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Replace the LANIC: 
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Flowchart 6. Identifying MAU/ThrnlVIAl/ Power-On Faults 
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Flowchart 7 

Flowchart 7 checks the ability of the LANIC card to transmit and receive 
packets on the LAN cable by _/iising a known good loopback hood and 
MAU/ThinMAU. 

Note that both "25 ohm" and "50 ohm" subtests are performed. The "50 ohm" 
subtest verifies collision detection operation. This is important because the 
inability of a node to detect collisions can cause serious degradation of network 
performance. 
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Run Test 16 *25 ohm' subtest 

with a MAU Loopback hood 
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Run Test 16 *25 ohm' subtest 
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Flowchart 7. Testing Coax LAN Connection AUr Interface 



Troubleshooting Flowcharts 

A-17 



Flowchart 8 

Flowchart 8 systematically checks each AUI cable connecting the LANIC card 
to the LAN. Only the '25 ohm' test is used. 
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Run Test 16 *25 ohm' subtest 

with a MAU Loopback hood 
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Flowchart 8. Testing AUI Cables 
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Flowchart 9 

Using Test 16, Flowchart 9 checks the operation of the coaxial cable. Here, the 
loopback hood is removed, and the known good MAU/ThinMAU is attached to 
the coaxial cable in place of the originally installed MAU/ThinMAU. 

If the test now runs successfully, the originally installed MAU/ThinMAU is 
faulty. 

If the test still fails, the coaxial cable contains a fault. An open Tap, that is, one 
that does not make contact with the coaxial cable conductors, can be verified by 
repeating the test on a nearby Tap. A shorted Tap is not easily verified, since the 
entire cable will appear faulty. 

If the coaxial cable appears to be faulty, perform LANDIAG Test #17, Remote 
Node Tests, or refer to the LAN Link Hardware Troiihleshoolin^ Manual 
5955-768 1 (HP CE Handbook version 5959-22 17). 
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Flowchart 9. Testing MAU/ThinMAU Connection 
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Using Test 17 - The Remote Node Test (RNT) 



LANDIAG Test 1 7, the Remote Node Test, allows the user to send frames to and 
receive frames from remote nodes on the network. It can be used to isolate 
faults on the LAN between operational nodes. (Refer to Chapter 4, LAN Node 
Diagnostic, for details on performing LANDIAG Test 17.) 



Coaxial Cable LAN . For coax LANs, a binary search is used in conjunction with 
Test 17. In a binary search, the coax cable is first divided into two smaller LANs, 
which are each tested using Test 1 7. Each smaller LAN that fails is further 
divided, and the process continues until the LAN cable sections can no longer be 
conveniently divided. At that point, either the fault is found and corrected, or 
the faulty cable section is replaced. 

For other alternatives, refer to the LAN Link Hardware Trouble shooting Manual, 
5955-7681 (HP CE Handbook version 5959-2217). 



HP StarLAN . For a StarLAN with multiple Hubs, the Hubs are systematically 
isolated from one another while Test 17 is run between connected nodes. In this 
way, faults associated with a Hub or remote node can be quickly found. 

For more information, refer to the HP Star LA N Diagnostics and 
Troubleshooting Manual for PCs, 50906-90060. 
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Using Software Line Tests 



In this section, a brief discussion of software line tests used to troubleshoot 
Network Services application software is provided. Figure A-2 illustrates the 
coverage of various testing tools available. Network Services operation and use 
of troubleshooting tools are fully discussed in the NS3000/V Network Manager 
Reference Manual (Volume 1, 32344-90002; Volume 2, 32344-90012). 



1-Node Tests 



2-Node Line Tests 



QuickVal -j-- 
XPT Test ^- 



N0DE1 



Network Services 



NetlPC 



Network Transport 



Link Services 



LANDIAG 
1-16 



LANIC 



IT 



IT ^r-- "==■- JT 
or 

XPT Test 



QuickVal 



IPC Test 



XT 



"T 



LANDIAG 17 



N0DE2 



Network Services 



NetlPC 



Network Transport 



Link Services 



LANIC 



Figure A-2. Software Line Tests 



Troubleshooting Flowcharts 
A-23 



NOTE 

Before running the software line tests, use the LAN Node Diagnostic 
(LANDIAG) to ensure that there are no hardware problems. 

Also, the software should be reset -- shut down and restart the Network 
Transport and Network Services. Issue the command 

SHOWCOM Ideo; RESET 

to set the values of the SHOWCOM status display to zero. 

Be sure to refer to the NS3000/V Network Manager Reference Manual before 
attempting to perform software line tests. 



The HP 3000 LAN link includes three software line tests that can be used to 
verify the operation of the NS3000/V and LAN link software. The line tests are 
XPT, IPC and Quick Val. They can be run on a single node (software loopback), 
and between nodes. 

The XPT and IPC line tests are both interactive and use the NetlPC intrinsics. 
They verify operation of the Network Transport Level. 

Quick Val, which runs in batch mode, checks the network services. 
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Procedures 

Single Node Testing . On a single node, XPT verifies operation of the local 
Network Transport. If it is not functioning properly, the LAN problem has 
probably been found and further line testing may not be necessary. 

If the local Transport is operating properly, run QuickVal to verify operation of 
the services on the node. 

Finally, perform a two-node XPT line test. 

Two-Node Testing . The two-node XPT line test checks the remote Transport 
level, and the local and remote links. If this test reveals an error, refer to the 

NS3000/V Network Manager Reference Manual to interpret the results. 
Perform any hardware troubleshooting required. 

If both the single-node software loopback and two-node XPT line tests reveal no 
errors, run the IPC line test between nodes. (Running this test on a single node, 
ie software loopback, is not necessary since you already checked the transport.) 
The two-node IPC line test, in addition to checking the Network Transport and 
both links, uses Network Services, specifically Remote Process Management 
(RPM). This means that if this test fails, the problem probably lies within the 
RPM capabilities of the Network Services. 

If the IPC two-node test reveals no errors, you should run QuickVal between 
nodes to check all Network Services other than RPM. QuickVal tests the services 
by executing the intrinsics and commands of each service. 

If more than one service is not working, it could mean that DSDAD and its 
associated modules are not functioning properly. DSDAD is the control process 
for all Network Services. 
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Brisbane, Queensland 
Office 

Hewlett-Packard Australia Ltd. 

10 Payne Road 

THE GAP, Queensland 4061 

Tel: 30-4133 

Telex: 42133 

Cable: HEWPARD Brisbane 

A,C,CM,E,M,P 



Canberra, Australia 
Capital Territory 
OHice 

Hewlett-Packard Australia Ltd. 

121 Wollongong Street 

FYSHWICK,A.C.T.2609 

Tel: 80 4244 

Telex: 62650 

Cable: HEWPARD Canberra 

C,CM,E,P 

Melbourne, Victoria 
Office 

Hewlett-Packard Australia Ltd. 

31-41 Joseph Street 

BUCKBURN, Victoria 3130 

Tel: 895-2895 

Telex: 31-024 

Cable: HEWPARD Melbourne 

A,C,CM,E,M,P 

Perth, Western Australia 
Office 

Hewlett-Packard Australia Ltd. 

261 Stirling Highway 

CLAREMONT,W.A.6010 

Tel: 383-2188 

Telex: 93859 

Cable: HEWPARD Perth 

A,C,CM,E,M,P 

Sydney, New South 
Wales Office 

Hewlett-Packard Australia Ltd. 

17-23 Talavera Road 

P.O. Box 308 

NORTH RYDE, NSW. 2113 

Tel: 888-4444 

Telex: 21561 

Cable: HEWPARD Sydney 

A,C,CM,E,M,P 

AUSTRIA 

Hewlett-Packard Ges.m.b.h. 

VerkauisbUro Graz 

Grottenhotstrasse 94 

A-8052 GRAZ 

Tel: (0316) 291 56 60 

Telex: 32375 

C,E 

Hewlett-Packard Ges.m.b.h. 

Lieblgasse 1 

P.O. Box 72 

A-1222 VIENNA 

Tel: (0222) 2500-0 

Telex: 134425 HEPA A 

A,C,CM,E,M,P 

BAHRAIN 

Green Salon 

P.O. Box 557 

MANAMA 

Tel: 255503-255950 

Telex: 8441 

P 

Wael Pharmacy 

P.O. Box 648 

MANAMA 

Tel: 256123 

Telex: 8550 WAEL BN 

E,M 

Zayani Computer Systems 
218 Shaik Mubarak Building 
Government Avenue 
P.O. Box 5918 
MANAMA 
Tel: 276278 
Telex: 9015 
P 



BELGIUM 

Hewlett-Packard Belgium S.A./N.V. 

Blvd de la Woluwe, 100 

Woluwedal 

B-1200 BRUSSELS 

Tel: (02) 762-32-db 

Telex: 23-494 paloben bru 

A,C,CM,E,M,P 

BERMUDA 

Applied Computer Technologies 
Atlantic House Building 
Par-La-Ville Road 
Hamilton 5 
Tel: 295-1616 
P 

BRAZIL 

Hewlett-Packard do Brasil 

I.e.C. Ltda. 

Alameda Rio Negro, 750 

Alphaville 

06400 BARUERI SP 

Tel: (Oil) 421.1311 

Telex: (Oil) 33872 HPBR-BR 

Cable: HEWPACK Sao Paulo 

A,C,CM,E,M,P 

Hewlett-Packard do Brasil 

I.e.C. Ltda. 

Praia de Botafago 228 

6° Andar-conj 614 

Edificio Argentina - Ala A 

22250 RIO DE JANEIRO 

Tel: (021) 552-6422 

Telex: 21905 HPBR-BR 

Cable: HEWPACK Rio de Janeiro 

A,C,CM,E,P* 

Convex/Van Den 

Rua Jose Bonifacio 

458 Todos Os Santos 

CEP 20771 

RIO DE JANEIRO, R J 

Tel: 591-0197 

Telex: 33487 EGLB BR 

A 

ANAMED I.C.E.I. Ltda. 
Rua Bage, 103 
04012 SAO PAULO, SP 
Tel: (Oil) 572-6537 
Telex: 24720 HPBR-BR 
M 

Datatronix Electronica Ltda. 
Av. Pacaembu746-C11 
SAO PAULO, SP 
Tel: (118)260111 
CM 

CAMEROON 

Beriac 
B. P. 23 
DOUALA 

Tel: 420153 
Telex: 5351 
C,P 

CANADA 

Alberta 

Hewlett-Packard (Canada) Ltd. 
3030 3rd Avenue N.E. 
CALGARY, Alberta T2A6T7 
Tel: (403) 235-3100 
A,C,CM,E*,M,P* 

Hewlett-Packard (Canada) Ltd. 
11120-178th Street 
EDMONTON, Alberta T5S1P2 
Tel; (403) 486-6666 
A,C,CM,E,M,P 



Q 
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CANADA (Cont'd) 

British Columbia 

Hewlett-Packard (Canada) Ltd. 

10691 Shellbridge Way 

RICHMOND, 

Britisti Columbia V6X 2W7 

Tel: (604) 270-2277 

Telex: 610-922-5059 

A,C,CM,E*,M,P* 

Hewlett-Packard (Canada) Ltd. 
121 - 3350 Douglas Street 
VICTORIA, British Columbia V8Z 3L1 
Tel: (604) 381-6616 
C 

Manitoba 

Hewlett-Packard (Canada) Ltd. 
1825 Inkster Blvd. 
WINNIPEG, Manitoba R2X1R3 
Tel: (204) 694-2777 
A,C,CM,E,M,P* 

New Brunswicl( 

Hewlett-Packard (Canada) Ltd. 

814 Main Street 

MONCTON, New Brunswick E1C 1E6 

Tel: (506) 855-2841 

C 

Nova Scotia 

Hewlett-Packard (Canada) Ltd. 

Suite 111 

900 Windmill Road 

DARTMOUTH, Nova Scotia B3B 1P7 

Tel: (902) 469-7820 

C,CM,E*,M,P* 

Ontario 

Hewlett-Packard (Canada) Ltd. 
3325 N. Service Rd., Unit 3 
BURLINGTON, Ontario L7N 3G2 
Tel: (416) 335-8644 
CM* 

Hewlett-Packard (Canada) Ltd. 
496 Days Road 
KINGSTON, Ontario K7M 5R4 
Tel: (613) 384-2088 
C 

Hewlett-Packard (Canada) Ltd. 
552 Newbold Street 
LONDON, Ontario N6E 2S5 
Tel: (519) 686-9181 
A,C,CM,E*,M,P* 

Hewlett-Packard (Canada) Ltd. 
6877 Goreway Drive 
MIS8I88AUGA, Ontario L4V 1M8 
Tel: (416) 678-9430 
A,C,CM,E,M,P 

Hewlett-Packard (Canada) Ltd. 
2670 Queensview Dr. 
OHAWA, Ontario K2B8K1 
Tel: (613) 820-6483 
A,C,CM,E*,M,P* 

Hewlett-Packard (Canada) Ltd. 
The Oaks Plaza, Unit #9 
2140 Regent Street 
SUDBURY, Ontario, P3E 588 
Tel: (705) 522-0202 
C 

Hewlett-Packard (Canada) Ltd. 
3790 Victoria Park Ave. 
WILLOWDALE, Ontario M2H 3H7 
Tel: (416) 499-2550 
C 



Quebec 

Hewlett-Packard (Canada) Ltd. 
17500 Trans Canada Highway 
South Service Road 
KIRKUND, Quebec H9J 2X8 
Tel: (514) 697-4232 
A,C,CM,E,M,P* 

Hewlett-Packard (Canada) Ltd. 
1150 rue Claire Fontaine 
QUEBEC CITY, Quebec G 1 R 5G4 
Tel: (418) 648-0726 
C 

Hewlett-Packard (Canada) Ltd. 

130 Robin Crescent 

SASKATOON, Saskatchewan S7L 6M7 

Tel: (306) 242-3702 

C 

CHILE 

ASC Ltda. 
Austria 2041 
SANTIAGO 

Tel: 223-5946, 223-6148 
Telex: 340192 ASC CK 
C,P 

Isical Ltda. 

Av. Italia 634 Santiago 

Casilla 16475 

SANTIAGO 9 

Tel: 222-0222 

Telex: 440283 JCYCL CZ 

CM,E,M 

Metroiab S.A. 

Monjitas 454 of. 206 

SANTIAGO 

Tel: 395752, 398296 

Telex: 340866 METLAB CK 

A 

Olympia (Chile) Ltda, 

Av. Rodrigo de Araya 1045 

Casilla 256-V 

SANTIAGO 21 

Tel: 225-5044 

Telex: 340892 OLYMP 

Cable: Olympiachile Santiagochile 

C,P 



CHINA. People's 
Republic of 

China Hewlett-Packard, Ltd. 
47/F China Resources BIdg. 
26 Harbour Road 
HONGKONG 
Tel: 5-8330833 
Telex: 76793 HPA HX 
Cable: HP ASIA LTD 
A*,M* 

China Hewlett-Packard, Ltd. 

P.O. Box 9610, Beijing 

4th Floor, 2nd Watch Factory Main 

BIdg, 

Shuang Yu Shu, Bel San Huan Rd. 

Hal Dian District 

BEUING 

Tel: 28-0567 

Telex: 22601 CTSHP CN 

Cable: 1920 Beijing 

A,C,CM,E,M,P 



COLOMBIA 

Instrumentaci6n 

H. A. Langebaek & Kier S.A. 

Carrera 4A No. 52A-26 

Apartado Aereo 6287 

BOGOTA 1, DE. 

Tel: 212-1466 

Telex: 44400 INST CO 

Cable: AARIS Bogota 

CM,E,M 

Nefromedicas Ltda. 
Calle 123 No. 9B-31 
Apartado Aereo 100-958 
BOGOTA D.E., 10 
Tel: 213-5267, 213-1615 
Telex: 43415 HEGAS CO 
A 

Compumundo 
Avenlda 15 # 107-80 
BOGOTA DE. 
Tel: 214-4458 
Telex: 45466 MARICO 
P 

Carvajal, S.A. 

Calle 29 Norte No. 6A-40 

Apartado Aereo 46 

CALI 

Tel: 368-1111 

Telex: 55650 

C,E,P 

CONGO 

Seric-Congo 
B. P. 2105 
BRAZZAVILLE 

Tel: 815034 
Telex: 5262 

COSTA RICA 

Cientifica Costarricense S.A. 

Avenida 2, Calle 5 

San Pedro de Montes de Oca 

Apartado 10159 

SAN JOSE 

Tel: 24-38-20, 24-08-19 

Telex: 2367 GALGUR CR 

CM,E,M 

CYPRUS 

Telerexa Ltd. 

P.O. Box 4809 

14C Stassinos Avenue 

NICOSIA 

Tel: 62698 

Telex: 2894 LEVIDO CY 

E,M,P 

DENMARK 

Hewlett-Packard A/S 
Datavej 52 
DK-3460 BIRKEROD 
Tel: (02) 81-66-40 
Telex: 37409 hpas dk 
A,C,CM,E,M,P 

Hewlett-Packard A/S 
Rolighedsvej 32 
DK-8240 RISSKOV, Aarhus 
Tel: (06) 17-60-00 
Telex: 37409 hpas dk 
C,E 

DOMINICAN REPUBLIC 

MIcroprog S.A. 

Juan Tomds Mejia y Cotes No. 60 

Arroyo Hondo 

SANTO DOMINGO 

Tel: 565-6268 

Telex: 4510 ARENTADR (RCA) 
P 



ECUADOR 

CYEDE Cia. Ltda. 
Avenida Eloy Alfaro 1749 



Casilla 6423 CCI 

QUITO 

Tel: 450-975, 243-052 

Telex: 22548 CYEDE ED 

CM,E,P 

Medtronics 

Valladolid 524 Madrid 

P.O. 9171, QUITO 

Tel: 223-8951 

Telex: 2298 ECKAME ED 

A 

Hospitaiar S.A. 

Robles 625 

Casilla 3590 

QUITO 

Tel: 545-250, 545-122 

Telex: 2485 HOSPTL ED 

Cable: HOSPITALAR-Quito 

M 

Ecuador Overseas Agencies C.A. 

Calle 9 de Octubre #818 

P.O. Box 1296, Guayaquil 

QUITO 

Tel: 306022 

Telex: 3361 PBCGYE ED 

M 



EGYPT 

Sakrco Enterprises 
70, Mossadak Str. 
Ookki, Giza 
CAIRO 
Tel: 706440 
Telex: 93146 
C 

International Engineering Associates 

24 Hussein Hegazi Street 

Kasr-el-AIn 

CAIRO 

Tel: 23829, 21641 

Telex: 93830 lEA UN 

Cable: INTEGASSO 

E,M* 

S.S.C. Medical 

40 Gezerat El Arab Street 

Mohandessin 

CAIRO 

Tel: 803844, 805998, 810263 

Telex: 20503 SSC UN 

M* 

EL SALVADOR 

IPESA de El Salvador S.A. 

29 Avenida Norte 1223 

SAN SALVADOR 

Tel: 26-6858, 26-6868 

Telex: 20539 IPESA SAL 

A,C,CM,E,P 

ETHIOPIA 

Seric-Ethiopia 
P.O. Box 2764 
ADDIS ABABA 

Tel: 185114 
Telex: 21150 
C,P 

FINLAND 

Hewlett-Packard Oy 
PiispankalliontJe 17 
02200 ESPOO 
Tel: 00358-0-88721 
Telex: 121563 HEWPA SF 
A,C,CM,E,M,P 



FRANCE 

Hewlett-Packard France 
Z.I. Mercure B 
Rue Berthelot 
13763 Les Milles Cedex 
AIX-EN-PROVENCE 
Tel: (42) 59-41-02 
Telex: 410770F 
A,C,E,M,P' 

Hewlett-Packard France 
64, rue Marchand Saillant 
61000 ALENCON 
Tel: (33) 29 04 42 

Hewlett-Packard France 
28 rue de la Republique 
Boite Postale 503 
25026 BESANCON Cedex 
Tel: (81) 83-16-22 
Telex: 361157 
CM 

Hewlett-Packard France 
Chemin des Mouiiles 
Boite Postale 162 
69130 ECULLY Cedex (Lyon) 
Tel: (78) 833-81-25 
Telex: 310617F 
A,CE,M 

Hewlett-Packard France 

Pare d'activit6s du Bols Briard 

2, avenue du Lac 

91040 EVRY Cedex 

Tel: 6 077-96 60 

Telex: 6923 15F 

E 

Hewlett-Packard France 

5, avenue Raymond Chanas 

38320 EYBENS (Grenoble) 

Tel: (76) 62-57-98 

Telex: 980124 HP GRENOB EYBE 

C 

Hewlett-Packard France 
Rue Fernand. Forest 
Z.A. Kergaradec 
29239 60UESN0U 
Tel: (98) 41-87-90 

Hewlett-Packard France 

Centre d'affaires Paris-Nord 

Bailment Ampere 

Rue de la Commune de Paris 

Boite Postale 300 

93153 LEBLANC-MESML 

Tel: (1) 865-44-52 

Telex:211032F 

C,E.M 

Hewlett-Packard France 
Pare d'activitte Cadera 
Quartier Jean-Mermoz 
Avenue du President JF Kennedy 
F-33700 MERIQNAC (Bordeaux) 
Tel: (56) 34-00-84 
Telex: 550105F 
CE,M 

Hewlett-Packard France 
Immueble "Les 3 B" 
Nouveau chemin de la Garde 
ZAC du Bois Briand 
44085 NANTES Cedex 
Tel: (40) 50-32-22 
Telex:711085F 
C" 

Hewlett-Packard France 
125, rue du Faubourg Bannier 
45000 ORLEANS 
Tel: (38) 68 01 63 
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lANCE (Cont'd) 

wlett-Packard France 

le Industrielle de Courtaboeuf 

jnue des Tropiques 

M7 Les Ulis Cedex ORSAY 

: (6) 907-78-25 

ex: 600048F 

),CM,E,M,P 

wIett-Packard France 

ris Porte-Maillot 

, boulevard de L'Amiral-Bruix 

782 PARIS Cedex 16 

1: (1) 502-12-20 

lex: 613663F 

^.P 

wIett-Packard France 
4, Boulevard Tourasse 
000 PAU 
I: (59) 80 38 02 

iwlett-Packard France 
MI6e de la Bourgonnette 
>100 RENNES 
il: (99) 51-42-44 
ilex: 740912F 
CM,E,M,P* 

swIett-Packard France 
( avenue de Bretagne 
>100 ROUEN 
il: (35) 63-57-66 
jlex: 770035F 



ewlett-Packard France 
rue Thomas-Mann 
olte Postale 56 
^033 STRASBOURG Cedex 
jl: (88) 28-56-46 
slex: 890141 F 
,E,M,P* 

ewlett-Packard France 
a Pferipole III 

0, chemin du Pigeonnier de la C6pi6re 
-31083 TOULOUSE Cedex 
el: (61) 40-11-12 
elex: 531639F 
.,C,E,P* 

lewlett-Packard France 
, rue Baudin 
6000 VALENCE 
el: (75) 42 76 16 

lewlett-Packard France 

larolor 

:aC de Bois Briand 

,7640 V1QY (Metz) 

el: (8) 771 20 22 

lewlett-Packard France 
'arc d'activlt6 des Pr6s 

1, rue Papin 

)g658 VILLENEUVE D'ASCQ Cedex 
rel: (20) 47 78 78 
relex: 160124F 
:,E,M,P* 

5AB0N 

5ho Gabon 
'.0. Box 89 
JBREVILLE 

rel: 721 484 
Telex: 5230 



GERMAN FEDERAL 
REPUBLIC 

Hewlett-Packard GmbH 
Geschaftsstelle 
Keithstrasse 2-4 
D-1000 BERLIN 30 
Tel: (030) 21 99 04-0 
Telex: 018 3405 hpbin d 
A,C,E,M,P 

Hewlett-Packard GmbH 
Vertrlebszentrun SOdwest 
Schickardstrasse 2 
D-7030 BdBLINGEN 
Tel: (07031) 645-0 
Telex: 7265 743 hep 
A,C,CM,E,M,P 

Hewlett-Packard GmbH 
Vertriebszentrum West 
Berliner Strasse III 
D-4030 RATINGEN 3 
Tel: (02102) 494-0 
Telex: 589 070 hprad 
A,C,E,M,P 

Hewlett-Packard GmbH 
Geschaftsstelle 
Schleefstr. 28a 
D-4600 DORTMUND-41 
Tel: (0231) 45001 
Telex: 822858 hepdad 
A,C,E 

Hewlett-Packard GmbH 
Vertriebszentrum Mitte 
Hewlett-Packard-Strasse 
D-6380 BAD HOMBURG 
Tel: (06172) 400-0 
Telex: 410 844 hpbhg 
A,C,E,M,P 

Hewlett-Packard GmbH 
Vertriebszentrum Nord 
Kapstadtring 5 
D-2000 HAMBURG 60 
Tel: (040) 63804-1 
Telex: 021 63 032 hphh d 
A,C,E,M,P 

Hewlett-Packard GmbH 
Geschaftsstelle 
Heidering 37-39 
D-3000 HANNOVER 61 
Tel: (0511)5706-0 
Telex: 092 3259 
A,C,CM,E,M,P 

Hewlett-Packard GmbH 
Geschaftsstelle 
Rosslauer Weg 2-4 
D-6800 MANNHEIM 
Tel: (0621) 70 05-0 
Telex: 0462105 
A,C,E 

Hewlett-Packard GmbH 
Geschaftsstelle 
Messerschmittstrasse 7 
D-7910 NEU ULM 
Tel: (0731) 70 73-0 
Telex: 0712816 HP ULM-D 
A,C,E* 

Hewlett-Packard GmbH 
Geschaftsstelle 
Emmerlcher Strasse 13 
D-8500 NORNBERQ 10 
Tel: (091 1)5205-0 
Telex: 0623 860 hpnbg 
C,CM,E,M,P 



Hewlett-Packard GmbH 
Vertriebszentrum SOd 
Eschenstrasse 5 
[)-8028 TAUFKIRCHEN 
Tel: (089) 61 20 7-0 
Telex: 0524985 
A,C,CM,E,M,P 

Hewlett-Packard GmbH 

Geschaftsstelle 

Ermlisallee 

7517WALDBRONN2 

Tel: (07243) 602-0 

Telex: 782 838 hepk 

A,C,E 

GREAT BRITAIN 
See United Kingdom 

GREECE 

Hewlett-Packard A.E. 

178, Kifissias Avenue 

6th Floor 

Halandrl-ATHENS 

Greece 

Tel: 6471543, 6471673, 6472971 

Telex: 221 286 HPHLGR 

A,C,CM**,E,M,P 

Kostas Karaynnis S.A. 

8, Omirou Street 

ATHENS 133 

Tel: 32 30 303, 32 37 371 

Telex: 215962 RKAR GR 

A,C*,CM,E 

Impexin 
Intelect Div. 
209 Mesogion 
11525 ATHENS 
Tel: 6474481/2 
Telex: 216286 
P 

Haril Company 
38, Mlhalakopoulou 
ATHENS 612 
Tel: 7236071 
Telex: 218767 
M* 

Hellamco 
P.O. Box 87528 
18507 PIRAEUS 
Tel: 4827049 
Telex: 241441 
A 

GUATEMALA 

IPESA 

Avenida Reforma 3-48, Zona 9 

QUATEMAUCITY 

Tel: 316627, 314786 
Telex: 3055765 IPESA GU 
A,C,CM,E,M,P 

HONGKONG 

Hewlett-Packard Hong Kong, Ltd. 

G.P.O. Box 795 

5th Floor, Sun Hung Kai Centre 

30 Harbour Road 

HONGKONG 

Tel: 5-8323211 

Telex: 66678 HEWPA HX 

Cable: HEWPACK Hong Kong 

E,C,P 

CET Ltd. 

10th Floor, Hua Asia BIdg. 

64-66 Qloulester Road 

HONGKONG 

Tel: (5) 200922 

Telex: 85148 CET HX 

CM 



Schmidt & Co. (Hong Kong) Ltd. 
18th Floor, Great Eagle Centre 

23 Harbour Road 
HONGKONG 
Tel: 5-8330222 

Telex: 74766 SCHMC HX 
A,M 

ICELAND 

Hewlett-Packard Iceland 
Hoefdabakka 9 
110 Reykjavik 
Tel: (1) 67 1000 
A,C,CM,E,M,P 

INDIA 

Computer products are sold through 
Blue Star Ltd.AII computer repairs and 
maintenance service is done through 
Computer Maintenance Corp. 

Blue Star Ltd. 

SabrI Complex 2nd Floor 

24 Residency Rd. 
BANGALORE 560 025 
Tel: 55660, 578881 
Telex: 0845-430 
Cable: BLUESTAR 
A,C*,CM,E 

Blue Star Ltd. 
Band Box House 
Prabhadevi 
BOMBAY 400 025 
Tel: 4933101, 4933222 
Telex: 011-71051 
Cable: BLUESTAR 
A,M 

Blue Star Ltd. 

Sahas 

414/2 Vir Savarkar Marg 

Prabhadevi 

BOMBAY 400 025 

Tel: 422-6155, 422-6556 

Telex: 011-71193 BSSS IN 

Cable: FROSTBLUE 

A,C*,CM,E,M 

Blue Star Ltd. 

Kalyan, 19 Vishwas Colony 

Alkapuri, BORODA, 390 005 

Tel: 65235, 65236 

Cable; BLUE STAR 

A 

Blue Star Ltd. 
7 Hare Street 
CALCUnA700 001 
Tel: 230131, 230132 
Telex: 021-7655 
Cable: BLUESTAR 
A,M 

Blue Star Ltd. 

133 Kodambakkam High Road 

MADRAS 600 034 

Tel: 472056, 470238 

Telex: 041-379 

Cable: BLUESTAR 

A,M 

Blue Star Ltd. 
13 Community Center 
New Friends Colony 
NEW DELH1 110 065 
Tel: 633773, 634473 
Telex: 031-61120 
Cable: BLUEFROST 
A,C*,CM,E,M 



Blue Star Ltd. 
15/16 CWellesleyRd. 
PUNE411011 
Tel: 22775 
Cable: BLUE STAR 
A 

Blue Star Ltd. 
2-2-47/1108 BolarumRd. 
SECUNDERABAD500 003 
Tel: 72057, 72058 
Telex: 0155645 
Cable: BLUEFROST 
A,E 

Blue Star Ltd. 
T.C. 7/603 Poornlma 
Maruthunkuzhi 
TRIVANDRUM695 013 
Tel: 65799, 65820 
Telex: 0884-259 
Cable: BLUESTAR 
E 

Computer Maintenance Corporation 

Ltd. 

115, Sarojini Devi Road 

SECUNDERABAD500003 

Tel: 310-184, 345-774 

Telex: 031-2960 

C" 

INDONESIA 

BERCA Indonesia P.T. 

P.O.Box 496/Jkt. 

Jl. Abdul Muis 62 

JAKARTA 

Tel: 21-373009 

Telex: 46748 BERSAL lA 

Cable: BERSAL JAKARTA 

P 

BERCA Indonesia P.T. 
P.O.Box 2497/Jkt 
Antara BIdg., 12th Floor 
Jl. Medan Merdeka Selatan 17 
JAKARTA-PUSAT 
Tel: 21-340417, 341445 
Telex: 46748 BERSAL lA 
A,C,E,M 

BERCA Indonesia P.T. 

Jalan Kutal 24 

SURABAYA 

Tel: 67118 

Telex: 31146 BERSAL SB 

Cable: BERSAL-SURABAYA 

A*,E,M,P 

IRAQ 

Hewlett-Packard Trading S.A. 

Service Operation 

Al Mansoor City 9B/3/7 

BAGHDAD 

Tel: 551-49-73 

Telex: 212-455 HEPAIRAQ IK 

C 

IRELAND 

Hewlett-Packard Ireland Ltd. 

82/83 Lower Leeson Street 

DUBUN2 

Tel: 0001 608800 

Telex: 30439 

A,C,CM,E,M,P 

Cardiac Services Ltd. 

Kilmore Road 

Artane 

DUBUN5 

Tel: (01) 351820 

Telex: 30439 

M 



H 
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ISRAEL 

Eldan Electronic Instrument Ltd. 
P.O.Box 1270 
JERUSALEM 91000 
16, Ohallav St. 
JERUSALEM 94467 
Tel: 533 221, 553 242 
Telex: 25231 AB/PAKRD IL 
A,M 

Computation and Measurement 

Systems (CMS) Ltd. 

1 1 Masad Street 

67060 

TEL-AVIV 

Tel: 388 388 

Telex: 33569 Motil IL 

C,CM,E,P 

ITALY 

Hewlett-Packard Italiana S.p.A 

Traversa 99C 

Via Giullo Petroni, 19 

1-70124 BARI 

Tel: (080) 41-07-44 

CM 

Hewlett-Packard Italiana S.p.A. 

Via Emilia, 51 /C 

1-40011 BOLOGNA Anzola Dell'Emilia 

Tel: (051) 731061 

Telex: 511630 

C,E,M 

Hewlett-Packard Italiana S.p.A. 

Via Principe Nicola 43G/C 

1-95126 CATANIA 

Tel: (095) 37-10-87 

Telex: 970291 

C 

Hewlett-Packard Italiana S.p.A. 

Via G. Di Vittorlo 9 

1-20063 CERNUSCO 8UL 

NAVIGLK) 

(Milano) 

Tel: (02) 4459041 

Telex: 334632 

A,C,CM,E,M,P 

Hewlett-Packard Italiana S.p.A. 
Via C. Colombo 49 
1-20090 TREZZANO 8UL 
NAVIGUO 

(Milano) 

Tel: (02) 4459041 

Telex: 322116 

C 

Hewlett-Packard Italiana S.p.A. 

Via Nuova San Rocco a 

Capodimonte, 62/A 

1-80131 NAPOU 

Tel: (081) 7413544 

Telex: 710698 

A**,C,E,M 

Hewlett-Packard Italiana S.p.A. 
Viale G. Modugno 33 
1-16156 6EN0VA PEGU 
Tel: (010) 68-37-07 
Telex: 215238 
C,E 

Hewlett-Packard Italiana S.p.A. 

Via Pelizzo 15 

1-35128 PADOVA 

Tel: (049) 664888 

Telex: 430315 

A,C,E,M 



Hewlett-Packard Italiana S.p.A. 

Viale C. Pavese 340 

1-00144 ROMA EUR 

Tel: (06) 54831 

Telex: 610514 

A,C,E,M,P' 

Hewlett-Packard Italiana S.p.A. 
Via di Casellina 57/C 
1-50018 SCANOICCI-FIRENZE 

Tel: (055) 753863 
C,E,M 

Hewlett-Packard Italiana S.p.A. 

Corso Svizzera, 185 

1-10144 TORINO 

Tel: (Oil) 74 4044 

Telex: 221079 

A*,C,E 

IVORY COAST 

S.I.T.E.L. 

Societe Ivoirienne de 

Telecommunications 

Bd. Giscard d'Estaing 

Carrefour Marcory 

Zone 4. A. 

Boite postale 2580 

ABIDJAN 01 

Tel: 353600 

Telex: 43175 

E 

S.LT.L 

Immeuble "Le General" 

Av. du General de Gaulle 

01 BP 161 

ABIDJAN 01 

Tel: 321227 

C,P 

JAPAN 

Yokogawa-Hewlett-Packard Ltd. 

152-1, Onna 

ATSUGL Kanagawa, 243 

Tel: (0462) 25-0031 

CCM.E 

Yokogawa-Hewlett-Packard Ltd. 

Meiji-Seimei BIdg. 6F 

3-1 Hon Ctiiba-Ctio 

CHIBA,280 

Tel: 472 25 7701 

CE 

Yokogawa-Hewlett-Packard Ltd. 
Yasuda-Seimei Hiroshima BIdg. 
6-11, Hon-dori, Naka-ku 
HIROSHIMA, 730 
Tel: 82-241-0611 

Yokogawa-Hewlett-Packard Ltd. 

Towa Building 

2-3, Kaigan-dori, 2 Chome Chuo-ku 

KOBE, 650 

Tel: (078) 392-4791 

CE 

Yokogawa-Hewlett-Packard Ltd. 
Kumagaya Asahi 82 BIdg 
3-4 Tsukuba 

KUMA6AYA,Saitama360 
Tel: (0485) 24-6563 
CCM.E 

Yokogawa-Hewlett-Packard Ltd. 

Asahi Shinbun Daiichi Seimei BIdg. 

4-7, Hanabata-cho 

KUMAMOTO,860 

Tel: (096) 354-7311 

CE 



Yokogawa-Hewlett-Packard Ltd. 
Shin-Kyoto Center BIdg. 
614, Higashi-Shiokoji-cho 
Karasuma-Nishiiru 
Shiokoji-dori, Shimogyo-ku 
KYOTO, 600 
Tel: 075-343-0921 
CE 

Yokogawa-Hewlett-Packard Ltd. 

Mito Mitsui BIdg 

4-73, Sanno-maru, 1 Chome 

MITO, Ibaraki 310 

Tel: (0292) 25-7470 

CCM,E 

Yokogawa-Hewlett-Packard Ltd. 

Meiji-Seimei Kokubun BIdg. 7-8 

Kokubun, 1 Chome, Sendai 

MIYAGI, 980 

Tel: (0222)25-1011 

CE 

Yokogawa-Hewlett-Packard Ltd. 

Nagoya Kokusai Center Building 

47-1, Nagono, 1 Chome 

Nakamura-ku 

NAGOYA, 450 

Tel: (052) 571-5171 

CCM,E,M 

Yokogawa-Hewlett-Packard Ltd. 

Saikyoren Building 

1-2 Dote-machi, OHMIYA 

Saitama 330 

Tel: (0486) 45-8031 

Yokogawa-Hewlett-Packard Ltd. 
---Chuo BIdg., 
4-20 Nishinakajima, 5 Chome 
Yodogawa-ku 
OSAKA, 532 
Tel: (06) 304-6021 
Telex: YHPOSA 523-3624 
A,CCM,E,M,P* 

Yokogawa-Hewlett-Packard Ltd. 
27-15, Yabe, 1 Chome 
SAGAMIHARA Kanagawa, 229 
Tel: 0427 59-1311 

Yokogawa-Hewlett-Packard Ltd. 

Daiichi Seimei BIdg. 

7-1, Nishi Shinjuku, 2 Chome 

Shinjuku-ku,TOKY0 160 

Tel: 03-348-4611 

CE 

Yokogawa-Hewlett-Packard Ltd. 
29-21 Takaido-Hlgashi, 3 Chome 
Suginami-ku TOKYO 168 
Tel: (03)331-6111 
Telex: 232-2024 YHPTOK 
A,CCM,E,M,P* 

Yokogawa Hokushin Electric Corp. 

9-32 Nokacho 2 Chome 

2 Chome Musashino-shi 

TOKYO, 180 

Tel: (0422) 54-1111 

Telex: 02822-421 YEW MTK J 

A 

Yokogawa-Hewlett-Packard Ltd. 

Meiji-Seimei 

Utsunomiya Odori Building 

1-5 Odori, 2 Chome 

UTSUNOMIYA, Txhigi 320 

Tel: (0286) 33-1 153 

CE 



Yokogawa-Hewlett-Packard Ltd. 

Yasuda Seimei Yokohama Nishiguchi 

BIdg. 

30-4 Tsuruya-cho, 3 Chome 

YOKOHAMA 221 

Tel: (045) 312-1252 

CE 

JORDAN 

Scientific and Medical Supplies Co. 

P.O. Box 1387 

AMMAN 

Tel: 24907, 39907 

Telex: 21456 SABCO JO 

CE,M,P 

KENYA 

ADCOM Ltd., Inc., Kenya 
P.O.Box 30070 
NAIROBI 

Tel: 331955 
Telex: 22639 
E,M 

KOREA 

Samsung Hewlett-Packard Co. Ltd. 

Dongbang Yeoeuido Building 

12-16th Floors 

36-1 Yeoeuido-dong 

Yongdeungpo-ku 

SEOUL 

Tel: 784-2666, 784-4666 

Telex: 25166 SAMSAN K 

A,CCM,E,M,P 

Young In Scientific Co., Ltd. 

Youngwha Building 

547 Shinsa Dong, Kangnam-ku 

SEOUL 135 

Tel: 5467771 

Telex: K23457 GINSCO 

A 

KUWAIT 

Al-Khaldiya Trading & Contracting 

P.O. Box 830 

SAFAT 

Tel: 424910, 411726 

Telex: 22481 AREEG KT 

Cable: VISCOUNT 

E,M,A 

Gulf Computing Systems 

P.O. Box 25125 

SAFAT 

Tel: 435969 

Telex: 23648 

P 

Photo & Cine Equipment 

P.O. Box 270 

SAFAT 

Tel: 2445111 

Telex: 22247 MATIN KT 

Cable: MATIN KUWAIT 

P 

W.J. Towell Computer Services 

P.O. Box 5897 

SAFAT 

Tel: 2462640 

Telex: 30336 TOWELL KT 

C 



LEBANON 

Computer Information Systems S.A.L. 

Chammas Building 

P.a Box 11-6274 Dora 

BEIRUT 

Tel: 89 40 73 

Telex: 42309 

CE,M,P 



LIBERIA 

Unichemicals Inc. 
P.O. Box 4509 
MONROVIA 

Tel: 224282 
Telex: 4509 
E 

MADAGASCAR 

Technique et Precision 
12, rue de Nice 
P.O. Box 1227 
101 ANTANANARIVO 
Tel: 22090 
Telex: 22255 
P 

LUXEMBOURG 

Hewlett-Packard Belgium S.A./N.V. 

Blvd de la Woluwe, 100 

Woluwedal 

B-1200 BRUSSELS 

Tel: (02) 762-32-00 

Telex: 23-494 paloben bru 

A,CCM,E,M,P 

MALAYSIA 

Hewlett-Packard Sales (Malaysia) 

Sdn. Bhd. 

9th Floor 

Chung Khiaw Bank Building 

46, Jalan Raja Laut 

KUALA LUMPUR 

Tel: 03-986555 

Telex: 31011 HPSM MA 

A,CE,M,P* 

Protel Engineering 

P.O.Box 1917 

Lot 6624, Section 64 

23/4 Pending Road 

Kuching, SARAWAK 

Tel: 36299 

Telex: 70904 PROMAL MA 

Cable: PROTELENG 

A,E,M 

MALTA 

Philip Toledo Ltd. 

Birkirkara P.O. Box 1 1 

Notabile Rd. 

MRIEHEL 

Tel: 447 47, 455 66 

Telex: 1649 

E,M,P 

MAURITIUS 

Blanche Birger Co. Ltd. 

18, Jules Koenig Street 

PORT LOUIS 

Tel: 20828 

Telex: 4296 

P 

MEXICO 

Hewlett-Packard de Mexico, S.A. 

Francisco J. Allan #30 

Colonia Nueva 

Los Angeles 27140 

COAHUILA,Torreon 

Tel: 37220 

P 



Hewlett-Packard de Mexico, S.A. 

Monti Morelos 299 

Fraccionamiento Loma Bonita 45060 

GUADALAJARA, Jalisco 

Tel: 316630/314600 

Telex: 0684 186 ECOME 

P 
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MEXICO (Cont'd) 

Microcomputadoras Hewlett-Packard, 

S.A. 

Monti Pelvoux 115 

LOS LOMAS, Mexico, D.F. 

Tei: 520-9127 

P 

Hewlett-Pacl<ard Mexicana, S.A. 

de C.V. 

Av. Periferico Sur No. 6501 

Tepepan, Xochimiico 

16020 MEXICO D.F. 

Tei: 6-76-46-00 

Teiex: 17-74-507 HEWPACK MEX 

A,C,CM,E,M,P 

Hewiett-Packard De Mexico (Poianco) 
Avenlda Ejercito Nacional #579 
2day3er pjgo 

Colonia Granada 11560 
MEXICO O.F. 

Tei: 254-4433 
P 

Hewiett-Packard De Mexico, S.A. 

de C.V. 

Czda. del Valle 

409 Ote. 4th Piso 

Colonia del Valle 

Municipio de Garza Garcid 

66220 MONTERREY, Nuevo Le6n 

Tel: 78 42 41 

Telex: 038 410 

P 

MOROCCO 

Etablissement Hubert Doibeau & Fiis 

81 rue KaratchI 

B.P. 11133 

CASABUNCA 

Tel: 3041-82, 3068-38 

Telex: 23051, 22822 

E 

Gerep 

2, rue Agadir 

Boite Postale 156 

CASABUNCA 01 

Tel: 272093, 272095 

Telex: 23 739 

P 

Sema-Maroc 
Dept. Seric 
6, rue Lapebie 
CASABUNCA 
Tel: 260980 
Telex: 21641 
C,P 

NETHERLANDS 

Hewlett-Packard Nederland B.V. 

Startbaan 16 

1187XRAMSTELVEEN 

P.O. Box 667 

NL1180 AR AMSTELVEEN 

Tel: (020) 547-6911 

Telex: 13 216 HEPA NL 

A,C,CM,E,M,P 

Hewiett-Packard Nederland B.V. 

Bongerd 2 

NL 2906VK CAPELLE A/D USSEL 

P.O. Box 41 

NL 2900AA CAPELLE A/D USSEL 

Tel: (10) 51-64-44. 

Telex: 21261 HEPAC NL 

C,E 



Hewiett-Packard Nederland B.V. 
Pastoor Petersstraat 134-136 
NL 5612 LV EINDHOVEN 
P.O. Box 2342 
NL 5600 CH EINDHOVEN 
Tei: (040) 326911 
Telex: 51484 hepae nl 
A,C,E,M,P 

NEW ZEALAND 

Hewiett-Packard (N.Z.) Ltd. 

5 Owens Road 

P.O. Box 26-189 

Epsom, AUCKLAND 

Tei: 687-159 

Cable: HEWPAK Auckland 

C,CM,E,P* 

Hewlett-Packard (N.Z.) Ltd. 

4-12 Cruickshank Street 

Kilblrnle, WELLINGTON 3 

P.O. Box 9443 

Courtenay Place, WELLINGTON 3 

Tei: 877-199 

Cable: HEWPACK W/eiiington 

C,CM,E,P 

Northrop Instruments & Systems Ltd. 

369 Khyber Pass Road 

P.O. Box 8602 

AUCKUND 

Tel: 794-091 

Telex: 60605 

A,M 

Northrop Instruments & Systems Ltd. 

IIOMandevilleSt. 

P.O. Box 8388 

CHRISTCHURCH 

Tel: 488-873 

Telex: 4203 

A,M 

Northrop Instruments & Systems Ltd. 

Sturdee House 

85-87 Ghuznee Street 

P.O. Box 2406 

WELLMGTON 

Tei: 850-091 

Telex: NZ 3380 

A,M 

NIGERIA 

Elmeco Nigeria Ltd. 

46, Calcutta Crescent Apapa 

P.O. Box 244and 

UGOS 

E 

NORTHERN IRELAND 
See United Kingdom 

NORWAY 

Hewlett-Packard Norge A/S 

Foike Bernadottes vel 50 

P.O. Box 3558 

N-5033 FYLLINGSDALEN (Bergen) 

Tel: 0047/5/16 55 40 

Telex: 76621 hpnas n 

C,E,M 

Hewiett-Packard Norge A/S 
Osterndaien 16-18 
P.O. Box 34 
N-1345 O&TERAS 
Tel: 0047/2/17 11 80 
Telex: 76621 hpnas n 
A,C,CM,E,M,P 



OMAN 

Khimjil Ramdas 
P.O. Box 19 
MUSCAT/SULTANATE OF OMAN 

Tei: 745601 

Teiex: 5289 BROKER MB MUSCAT 

P 

Suhail & Saud Bahwan 
P.O.Box 169 
MUSCAT/SULTANATE OF OMAN 

Tel: 734201 

Telex: 5274 BAHWAN MB 

E 

Imtac LLC 
P.O. Box 8676 
MUTRAH/SULTANATE OF OMAN 

Tel: 601695 

Telex: 5741 Tawoos On 

A,C,M 

PAKISTAN 

Mushko & Company Ltd. 

House No. 16, Street No. 16 

Sector F-6/3 

ISUMABAD 

Tel: 824545 

Cable: FEMUS Islamabad 

A,E,M,P* 

Mushko & Company Ltd. 
Oosman Chambers 
Abdullah Haroon Road 
KARACHI 0302 
Tei: 524131, 524132 
Telex: 2894 MUSKO PK 
Cable: COOPERATOR Karachi 
A,E,M,P* 

PANAMA 

Electronico Balboa, S.A. 

Calie Samuel Lewis, Ed. Alfa 

Apartado 4929 

PANAMA 5 

Tei: 64-2700 

Telex: 3483 ELECTRON PG 

A,CM,E,M,P 

PERU 

C(a Electro M6dica S.A. 

Los Flamencos 145, Ofc. 301/2 

San Isldro 

Casllla 1030 

LIMA1 

Tel: 41-4325, 41-3705 

Telex: Pub. Booth 25306 PEC PISIDR 

CM,E,M,P 

SAMS 

Arenlda RepublIca de Panama 3534 

San Isldro, LIMA 

Tei: 419928/417108 

Telex; 20450 PE LIBERTAD 

A,C,P 

PHILIPPINES 

The Online Advanced Systems Corp. 

2nd Floor, Electra House 

115-117 Esteban Street 

Legaspi Village, Makati 

P.O. Box 1510 

Metro MANIU 

Tel: 815-38-10 (up to 16) 

Telex: 63274 ONLINE PN 

A,C,E,M,P 



PORTUGAL 

Mundinter Intercambio 

Mundial de Com§rcio S.A.R.L. 

Av. Antonio Augusto Aguiar 138 

Apartado 2761 

LISBON 

Tei: (19) 53-21-31, 53-21-37 

Telex: 16691 munter p 

M 

Soqulmica 

Av. da Liberdade, 220-2 

1298 LISBOA Codex 

Tei: 56-21-82 

Teiex: 13316 SABASA 

A 

Teiectra-Empresa T6cnica de 

Equipmentos EI6ctricos S.A.R.L. 

Rua Rodrigo da Fonseca 103 

P.O. Box 2531 

USB0N1 

Tel: (19) 68-60-72 

Telex: 12598 

CM,E 

C.P.C.S.I. 

Rua de Costa Cabral 575 

4200 PORTO 

Tel: 499174/495173 

Telex: 26054 

C,P 

PUERTO RICO 

Hewlett-Packard Puerto Rico 
101 Murtoz Rivera Av 
Esu. Calie Ochoa 
HATOREY, Puerto Rico 00918 
Tel: (809) 754-7800 
A,C,CM,M,E,P 

QATAR 

Computer Arabia 

P.O. Box 2750 

DOHA 

Tel: 428555 

Telex: 4806 CHPARB 

P 

Nasser Trading & Contracting 

P.O.Box 1563 

DOHA 

Tel: 422170 

Telex: 4439 NASSER DH 

M 

SAUDI ARABIA 

Modern Electronics Establishment 
Hewlett-Packard Division 
P.O. Box 281 
Thouqbah 
AL-KHOBAR 31952 
Tel; 895-1760, 895-1764 
Telex: 671 106 HPMEEK SJ 
Cable: ELECTA AL-KHOBAR 
C.E,M 

Modern Electronics Establishment 

Hewlett-Packard Division 

P.O. Box 1228 

JEDOAH 

Tel: 644 96 28 

Telex: 4027 12 FARNAS SJ 

Cable: ELECTA JEDDAH 

A.C,CM,E,M,P 

Modern Electronics Establishment 

Hewlett-Packard Division 

P.O.Box 22015 

RIYADH 11495 

Tel: 476-3030 

Telex: 202049 MEERYD SJ 

A,C,CM,E,M,P 



Abdul Ghani El Ajou Corp. 

P.O. Box 78 

RIYADH 

Tel: 40 41 717 

Teiex: 200 931 EL AJOU 

P 

SCOTLAND 

See United Kingdom 

SENEGAL 

Societe Hussein Ayad & Cie. 

76, Avenue Georges Pompidou 

B.P. 305 

DAKAR 

Tei; 32339 

Cable: AYAD-Dakar 

E 

Moneger Distribution S.A. 

1, Rue Parent 

B.P. 148 

DAKAR 

Tel: 215 671 

Teiex: 587 

P 

Systeme Service Conseil (SSC) 

14, Avenue du Parachois 

DAKAR ETOILE 

Tel: 219976 

Telex: 577 

C,P 

SINGAPORE 

Hewlett-Packard Singapore (Sales) 

Re. Ltd. 

08-00 Inchcape House 

450-2 Alexandra Road 

Alexandra P.O. Box 58 

SINGAPORE, 91 15 

Tel; 4731788 

Telex: 34209 HPSGSO RS 

Cable: HEWPACK, Singapore 

A,C,E,M,P 

Dynamar International Ltd. 

Unit 05-11 Block 6 

Kolam Ayer Industrial Estate 

SINGAPORE 1334 

Tel; 747-6188 

Telex; 26283 RS 

CM 

SOUTH AFRICA 

Hewlett-Packard So Africa (Pty.) Ltd. 
P.O. Box 120 

Howard Place CAPE PROVINCE 7450 
Pine Park Center, Forest Drive, Pine- 
lands 

CAPE PROVINCE 7405 
Tel; (021) 53 7954 
Telex: 57-20006 
A,C,CM,E,M,P 

Hewlett-Packard So Africa (Ry.) Ltd. 

2nd Floor Juniper House 

92 Overport Drive 

DURBAN 4067 

Tel: (031) 28-4178 

Telex: 6-22954 

C 

Hewlett-Packard So Africa (Pty.) Ltd. 

6 Linton Arcade 

511 Cape Road 

Linton Grange 

PORT ELIZABETH 6001 

Tei: 041-301201 

Telex: 24-2916 

C 



m 
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SOUTH AFRICA (Cont'd) 

Hewlett-Packard So Africa (Pty.) Ltd. 

Fountain Center 

Kall<den Str. 

Monument Parl( Ext 2 

PRETORIA 0105 

Tel: (012) 45 57258 

Telex: 3-21063 

C,E 

Hewlett-Packard So Africa (Pty.) Ltd. 

Private Bag Wendywood 

8ANDT0N2144 

Tel: 802-5111, 802-5125 

Telex: 4-20877 SA 

Cable: HEWPACK Johannesburg 

A,C,CM,E,M,P 

SPAIN 

Hewlett-Packard Espaflola S.A. 

Calle Entenza, 321 

08029 BARCELONA 

Tel: 3/322 24 51, 321 73 54 

Telex: 52603 tipbee 

A,C,E,M,P 

Hewlett-Packard Espaftola S.A. 

Calle San Vicente S/N 

Edificio Albla II-7B 

48001 BILBAO 

Tel: 4/423 83 06 

A,C,E,M 

Hewlett-Packard Espaftoia S.A. 

Crta. de la Corufia, Km. 16, 400 

Las Rozas 

E-MADRIO 

Tel: (1)637.00.11 

Telex: 23515 HPE 

CM 

Hewlett-Packard Espaflola S.A. 

Avda. S. Francisco Javier, S/N 

Planta 10. Edificio Sevilla 2 

41005 8EVILU 

Tel: 54/64 44 54 

Telex: 72933 

A,C,M,P 

Hewlett-Packard Espaflola S.A. 
Isabel La Catolica, 8 
46004 VALENCIA. 
Tel: 0034/6/351 59 44 
C,P 

SWEDEN 

Hewlett-Packard Sverige AB 

Ostra Tullgatan 3 

S-21128MALMd 

Tel: (040) 70270 

Telex: (854) 17886 (via SpSnga 

office) 

C,P 

Hewlett-Packard Sverige AB 
Skalfioltsgatan 9, Kista 
Box 19 

S-16393 SPANGA 
Tel: (08) 750-2000 
Telex: (854) 17886 
Telefax: (08) 7527781 
A,C,CM,E.M,P 

Hewlett-Packard Sverige AB 

FrOtallsgatan 30 

S-42132 VASTRA-FRdLUNDA (Gottien- 

burg) 

Tel: (031) 49-09-50 

Telex: (854) 17886 (via Spdnga 

office) 

A,C,CM,E,M,P 



SUDAN Bangkok Business Equipment Ltd. 

Mediterranean Engineering & Trading 5/5-6 Dejo Road 

Co Ltd BANGKOK 

P.O. Box 1025 Tel: 234-8670, 234-8671 

T*!*^!?!'!' Telex: 87699-BEQUIPT TH 

Tel: 41184 

Telex: 24052 

C,P 



Cable: BUSIQUIPT Bangkok 
P 



SWITZERLAND 

Hewlett-Packard (Schweiz) AG 

Clarastrasse 12 

CH-4058 BASEL 

Tel: (61) 33-59-20 

A 

Hewlett-Packard (Schweiz) AG 
7, rue du Bois-du-Lan 
Case postale 365 
CH-1217 MEYRIN 1 
Tel: (0041)22-83-11-11 
Teiex:27333 HPAG CH 
CCM 

Hewlett-Packard (Schweiz) AG 

Allmend 2 

CH-8967 WIDEN 

Tel: (0041) 57 31 21 11 

Telex: 53933 hpag ch 

Cable: HPAG CH 

A,C,CM,E,M,P 

SYRIA 

General Electronic Inc. 

Nuri Basha Ahnaf Ebn Kays Street 

P.O. Box 5781 

DAMASCUS 

Tel: 33-24-87 

Telex: 411 215 

Cable: ELECTROBOR DAMASCUS 

E 

Middle East Electronics 
P.O.Box 2308 
Abu Rumaneh 
DAMASCUS 
Tel: 33 45 92 
Telex: 411 771 
M 

TAIWAN 

Hewlett-Packard Taiwan 

Kaohsiung Office 

11/F, 456, Chung Hsiao 1st Road 

KAOHSIUNG 

Tel: (07) 2412318 

C,E 

Hewlett-Packard Taiwan 

8th Floor, Hewlett-Packard Building 

337 Fu Hsing North Road 

TAIPEI 

Tel: (02) 712-0404 

Telex: 24439 HEWPACK 

Cable:HEWPACK Taipei 

A,C,CM,E,M,P 

Ing Lih Trading Co. 

3rd Floor, 7 Jen-Ai Road, Sec. 2 

TAIPE1 100 

Tel: (02) 3948191 

Cable: INGLIH Taipei 

A 

THAILAND 

Unimesa Co. Ltd. 

30 Patpong Ave., Suriwong 

BANGKOK 5 

Tel: 235-5727 

Telex: 84439 Simonco TH 

Cable: UNIMESA Bangkok 

A,C,E,M 



TOGO 

Societe Africaine De Promotion 

Immeuble Sagap 

22, Rue d'Atakpame 

B.P. 4150 

LOME 

Tel: 21-62-88 

Telex: 5304 

P 

TRINIDAD ft TOBAGO 

Caribbean Telecoms Ltd. 

Corner McAllister Street & 

Eastern Main Road, Laventille 

P.O. Box 732 

PORT-OF-SPAIN 

Tel: 624-4213 

Telex: 22561 CARTEL WG 

Cable: CARTEL, PORT OF SPAIN 

CM,E,M.P 

Computer and Controls Ltd. 

P.O. Box 51 

66 Independence Square 

PORT-OF-SPAIN 

Tel: 62-279-85 

Telex: 3000 POSTLX WG, ACCT 

L0090 AGENCY 1264 

A,P 

Feral Assoc. 

8 Fitzgerald Lane 

PORT-OF-SPAIN 

Tel: 62-36864, 62-39255 

Telex: 22432 FERALCO 

Cable: FERALCO 

M 

TUNISIA 

Precision Electronique S.A.R.L. 

31 Avenue de la Liberie 

TUNIS 

Tel: 893937 

Telex: 13238 

P 

Tunisie Electronique S.A.R.L. 
94, Av. Jugurtha, Mutuelleville 
1002 TUNIS-BELVEDERE 
Tel: 280144 
Telex: 13238 
C,E,P 

Corema S.A. 

23, bis Rue de Marseille 

TUNIS 

Tel: 253-821 

Telex: 14812 CABAM TN 

M 

TURKEY 

E.M.A 

MedihaEldemSokakNo. 41/6 

Yenisehir 

ANKARA 

Tel: 319175 

Telex: 46912 KTX TR 

Cable: EMATRADE ANKARA 

M 



Teknim Company Ltd. 

Iran Caddesi No. 7 

Kavaklidere 

ANKARA 

Tel: 275800 

Telex: 42155 TKNM TR 

E,CM 

Saniva Bilgisayar Sistemleri A.S. 

Buyukdere Caddesi 103/6 

Gayrettene 

ISTANBUL 

Tel: 1727030 

Telex: 26345 SANI TR 

C,P 

Best Inc. 

Esentepe, Gazeteciler SitesI 

Keskin Kalemy 

Sokak 6/3, Gayrettepe 

ISTANBUL 

Tel: 1721328 

Telex: 42490 

A 

UNITED ARAB 
EMIRATES 

Emitac Ltd. 

P.O. Box 1641 

SHARJAH 

Tel: 591181 

Telex: 68136 EMITAC EM 

Cable: EMITAC SHARJAH 

E,C,M,P,A 

Emitac Ltd. 
P.O. Box 2711 
ABU DHABI 

Tel: 820419-20 

Cable: EMITACH ABUDHABI 

Emitac Ltd. 
P.O. Box 8391 
DUBAI, 
Tel: 377591 

Emitac Ltd. 
P.O. Box 473 
RASALKHAIMAH 

Tel: 28133, 21270 

UNITED KINGDOM 

GREAT BRITAIN 

Hewlett-Packard Ltd. 
Trafalgar House 
Navigation Road 
ALTRINCHAM 
Cheshire WA14 1NU 
Tel: 061 928 6422 
Telex: 668068 
A,C,E,M,P 

Hewlett-Packard Ltd. 

Miller House 

The Ring, BRACKtKLL 

Berks RG12 1XN 

Tel: 0344 424898 

Telex: 848733 

E 

Hewlett-Packard Ltd. 
Elstree House, Elstree Way 
BOREHAMWOOD, Herts WD6 1SG 
Tel: 01 207 5000 
Telex: 8952716 
CE 

Hewlett-Packard Ltd. 
Oakfield House, Oakfield Grove 
Clifton BRISTOL, Avon BS8 2BN 
Tel: 0272 736806 
Telex: 444302 
C,E,P 



Hewlett-Packard Ltd. 
Bridewell House 
9 Bridewell Place 
LONDON EC4V6BS 
Tel: 01 583 6565 
Telex: 298163 
C,P 

Hewlett-Packard Ltd. 

Pontefract Road 

NORMANTON, West Yorkshire WF6 1RN 

Tel: 0924 895566 

Telex: 557355 

C,P 

Hewlett-Packard Ltd. 
The Quadrangle 
106-118 Station Road 
REDHHl, Surrey RH1 IPS 
Tel: 0737 68655 
Telex: 947234 
C,E,P 

Hewlett-Packard Ltd. 

Avon House 

435 Stratford Road 

Shirley, SOLIHULL, West Midlands 

B90 4BL 

Tel: 021 745 8800 

Telex: 339105 

C,E,P 

Hewlett-Packard Ltd. 
West End House 
41 High Street, West End 
SOUTHAMPTON 
Hampshire S03 3DQ 
Tel: 0703 476767 
Telex: 477138 
C,P 

Hewlett-Packard Ltd. 
Harmon House 
No. 1 George Street 
UXBRIDGE, Middlesex UX81YH 
Tel: 895 720 20 
Telex: 893134/5 
C,CM,E,M,P 

Hewlett-Packard Ltd. 
King Street Lane 
Winnersh, WOKINGHAM 
Berkshire RG 11 5AR 
Tel: 0734 784774 
Telex: 847178 
A,C,E,M,P 

IRELAND 

NORTHERN IRELAND 

Hewlett-Packard (Ireland) Ltd. 

Carrickfergus Industrial Centre 

75 Belfast Road, Carrickfergus 

BELFAST BT38 8PH 

Tel: 09603 67333 

Telex: 747626 

CE 

SCOTLAND 

Hewlett-Packard Ltd. 
8 Woodside Place 
GUSGOW,G37QF 
Tel: 041 332 6232 
Telex: 779615 
CE 

Hewlett-Packard Ltd. 
SOUTH QUEENSFERRY 

West Lothian, EH30 9TG 
Tel: 031 331 1188 
Telex: 72682 
CCM,E.M,P 



SALES & SUPPORT OFFICES 

Arranged alphabetically by country 



[a 



UNITED STATES 

Alabama 

Hewlett-Packard Co. 

700 Century Park South, Suite 128 

BIRMINGHAM, AL 35226 

Tel: (205) 822-6802 

A,C,M,P* 

Hewlett-Packard Co. 
420 Wynn Drive 
HUNTSVILLE,AL 35805 
Tel: (205) 830-2000 
C,CM,E,M* 

Alaska 

Hewlett-Packard Co. 
3601 C St., Suite 1416 
ANCHORAGE, AK 99503 
Tel: (907) 563-8855 
C,E 

Arizona 

Hewlett-Packard Co. 
8080 Pointe Parkway West 
PHOENIX, AZ 85044 
Tel: (602) 273-8000 
A,C,CM,E,M,P 

Hewlett-Packard Co. 
3400 East Britannia Dr. 
BIdg. C, Suite 124 
TUCSON, AZ 85706 
Tel: (602) 573-7400 
C,E,M** 

California 

Hewlett-Packard Co. 
99 South Hill Dr. 
BRISBANE, CA 94005 
Tel: (415) 330-2500 
C 

Hewlett-Packard Co. 

5060 E. Clinton Avenue, Suite 102 

FRESNO, CA 93727 

Tel: (209) 252-9652 

CM 

Hewlett-Packard Co. 
1421 S. Manhattan Av. 
FULLERTON,CA 92631 
Tel: (714) 999-6700 
C,CM,E,M 

Hewlett-Packard Co. 
7408 Hollister Ave. #A 
GOUETA,CA93117 
Tel: (805) 685-6100 
C.E 

Hewlett-Packard Co. 
5400 W. Rosecrans Blvd. 
UWM)ALE,CA 90260 
Tel: (213) 643-7500 
Telex: 910-325-6608 
CM 

Hewlett-Packard Co. 
2525 Grand Avenue 
Long Beach, C A 90815 
Tel: (213) 498-1111 
C 

Hewlett-Packard Co. 
3155 Porter Drive 
PALO ALTO, CA 94304 
Tel: (415) 857-8000 
CE 

Hewlett-Packard Co. 
4244 So. Market Court, Suite A 
SACRAMENTO, CA 95834 
Tel: (916) 929-7222 
A*,CE,M 



Hewlett-Packard Co. 
9606 Aero Drive 
SAN DIEQO,CA 92123 
Tel; (619) 279-3200 
CCM,E,M 

Hewlett-Packard Co. 
5725 W. Las Positas Blvd. 
Pleasanton, CA 94566 
Tel: (415) 460-0282 
C 

Hewlett-Packard Co. 
3003 Scott Boulevard 
SANTA CLARA, CA 95054 
Tel: (408) 988-7000 
Telex: 910-338-0586 
A,C,CM,E 

Hewlett-Packard Co. 
2150 W. Hillcrest Dr. 
THOUSAND OAKS, CA 91320 
(805) 373-7000 
CCM,E 

Colorado 

Hewlett-Packard Co. 

2945 Center Green Court South 

Suite A 

BOULDER, CO 80301 

Tel: (303) 938-3005 

A,CE 

Hewlett-Packard Co. 
24 Inverness Place, East 
ENQLEWOOO, CO 80112 
Tel: (303) 649-5000 
A,C,CM,E,M 

Connecticut 

Hewlett-Packard Co. 
500 Sylvan Av. 
BRIDGEPORT, CT 06606 
Tel: (203) 371-6454 
CE 

Hewlett-Packard Co. 

47 Barnes Industrial Road South 

WALLINGFORD,CT 06492 

Tel: (203) 265-7801 

A,CCM,E,M 

Florida 

Hewlett-Packard Co. 
2901 N.W. 62nd Street 
FORT UUOERDALE,FL 33309 
Tel: (305) 973-2600 
CE,M,P* 

Hewlett-Packard Co. 
6800 South Point Parkway 
Suite 301 

JACKSONVILLE, FL 32216 
Tel: (904) 398-0663 
C*,M** 

Hewlett-Packard Co. 
6177 Lake Ellenor Drive 
ORLANDO, FL 32809 
Tel: (305) 859-2900 
A,CCM,E,P* 

Hewlett-Packard Co. 
4700 Bayou Blvd. 
Building 5 

PENSACOLA,FL 32503 
Tel: (904) 476-8422 
A,CM 

Hewlett-Packard Co. 
5550 W. Idlewild, 150 
TAMPA. FL 33614 
Tel: (813) 884-3282 
CE.M,P 



Georgia 

Hewlett-Packard Co. 
2000 South Park Place 
ATLANTA, GA 30339 
Tel: (404) 955-1500 
Telex: 810-766-4890 
A,C,CM,E,M,P* 

Hewlett-Packard Co. 
3607 Parkway Lane 
Suite 300 

NOflCROSS,GA 30092 
Tel: (404) 448-1894 
CE,P 

Hawaii 

Hewlett-Packard Co. 
Kawaiahao Plaza, Suite 190 
567 South King Street 
HONOLULU, HI 96813 
Tel: (808) 526-1555 
A,CE,M 

Idalio 

Hewlett-Packard Co. 
1 1309 Chinden Blvd. 
BOISE, ID 83707 
Tel: (208) 323-2700 
C 

iilinois 

Hewlett-Packard Co. 
304 Eldorado Road 
P.O. Box 1607 
BLOOMINGTON,IL 61701 
Tel: (309) 662-9411 
CM** 

Hewlett-Packard Co. 
525 W. Monroe, 1308 
CMCAGO,IL 60606 
Tel: (312) 930-0010 
C 

Hewlett-Packard Co. 
1200 East Diehl Road 
NAPERVILLE,IL 60566 
Tel: (312) 357-8800 
C 

Hewlett-Packard Co. 
5201 Tollview Drive 
ROLLING MEADOWS, IL 60008 
Tel: (312) 255-9800 
Telex: 910-687-1066 
A,CCM,E,M 

Indiana 

Hewlett-Packard Co. 
11911 N. Meridian St. 
CARMEL, IN 46032 
Tel: (317) 844-4100 
A,CCM,E,M 

Hewlett-Packard Co. 
3702 Rupp Drive 
R.WAYNE, IN 46815 
Tel: (219) 482-4283 
CE 

Iowa 

Hewlett-Packard Co. 
4070 22nd Av. SW 
CEDAR RAPIDS, lA 52404 

Tel: (319) 390-4250 
CE,M 

Hewlett-Packard Co. 
4201 Corporate Dr. 
WEST DES MOINES, lA 50265 
Tel: (515) 224-1435 
A**,CM** 



Kansas 

Hewlett-Packard Co. 

7804 East Funston Road, 203 

WICHITA, KS 67207 

Tel: (316) 684-8491 

CE 

Kentucicy 

Hewlett-Packard Co. 
10300 Linn Station Road, 100 
LOUISVILLE, KY 40223 
Tel: (502) 426-0100 
A,CM 

Louisiana 

Hewlett-Packard Co. 
160 James Drive East 
ST. ROSE, LA 70087 
P.O. Box 1449 
KENNER, LA 70063 
Tel: (504) 467-4100 
A,CE,M,P 

Maryland 

Hewlett-Packard Co. 
3701 Koppers Street 
BALTIMORE, MD 21227 
Tel: (301) 644-5800 
Telex: 710-862-1943 
A,CCM,E,M 

Hewlett-Packard Co. 
2 Choke Cherry Road 
ROCKVILLE,MD 20850 
Tel: (301) 948-6370 
A,CCM,E,M 

Massachusetts 

Hewlett-Packard Co. 
1775 Minuteman Road 
ANDOVER, MA 01810 
Tel: (617) 682-1500 
A,CCM,E,M,P* 

Hewlett-Packard Co. 
32 Hartwell Avenue 
LEXINGTON, MA 02173 
Tel: (617) 861-8960 
CE 

Micliigan 

Hewlett-Packard Co. 
4326 Cascade Road S.E. 
GRAND RAPIDS, Ml 49506 

Tel: (616) 957-1970 
CM 

Hewlett-Packard Co. 

39550 Orchard Hill Place Drive 

NOVI, Ml 48020 

Tel: (313) 349-9200 

A,CE,M 

Hewlett-Packard Co. 
1771 W. Big Beaver Road 
TROY, Ml 48084 
Tel: (313) 643-6474 
C 

Minnesota 

Hewlett-Packard Co. 
2025 W. Larpenteur Ave. 
ST. PAUL, MN 551 13 
Tel: (612) 644-1 100 
A,C,CM,E,M 

Missouri 

Hewlett-Packard Co. 

1001 E. 101st Terrace Suite 120 

KANSAS CITY, MO 64131-3368 

Tel: (816) 941-0411 

A,CCM,E,M 



Hewlett-Packard Co. 
13001 Hollenberg Drive 
BRIDGETON, MO 63044 
Tel: (314)344-5100 
A,CE,M 

Nebraska 

Hewlett-Packard 
10824 Old Mill Rd., Suite 3 
OMAHA, NE 68154 
Tel: (402)334-1813 
CE,M 

New Jersey 

Hewlett-Packard Co. 
120 W. Century Road 
PARAMU8, NJ 07653 
Tel: (201) 265-5000 
A,CCM,E,M 

Hewlett-Packard Co. 
20 New England Av. West 
PISCATAWAY,NJ 08854 
Tel: (201) 562-6100 
A,C,CM,E 

New Mexico 

Hewlett-Packard Co. 
7801 Jefferson N.E. 
ALBUQUERQUE, NM 87109 
Tel: (505) 292-1330 
CE,M 

New York 

Hewlett-Packard Co. 
5 Computer Drive South 
ALBANY, NY 12205 
Tel: (518)458-1550 
A,CE,M 

Hewlett-Packard Co. 
9600 Main Street 
CLARENCE, NY 14031 
Tel: (716) 759-8621 
CE 

Hewlett-Packard Co. 
200 Cross Keys Office Park 
FAIRPORT, NY 14450 
Tel: (716)223-9950 
A,CCM,E,M 

Hewlett-Packard Co. 
7641 Henry Clay Blvd. 
UVERPOOL, NY 13088 
Tel: (315) 451-1820 
A,CCM,E,M 

Hewlett-Packard Co. 

No. 1 Pennsylvania Plaza 

55th Floor 

34th Street & 8th Avenue 

MANHAHAN NY 10119 

Tel: (212) 971-0800 

CM* 

Hewlett-Packard Co. 
15 Myers Corner Rd. 
Hollowbrook Park, Suite 20 
WAPPINGER FALLS, NY 12590 
CM,E 

Hewlett-Packard Co. 
250 Westchester Avenue 
WHITE PLAINS, NY 10604 
Tel: (914)684-6100 
CCM,E 

Hewlett-Packard Co. 
3 Crossways Park West 
WOODBURY, NY 11797 
Tel: (516) 682-7800 
A,CCM,E,M 



SALES & SUPPORT OFFICES 

Arranged alphabetically by country 



UNITED STATES (Cont'd) 

North Carolina 

Hewlett-Packard Co. 
305 Gregson Dr. 
CARY.NC 27511 
Tel: (919) 467-6600 
C,CM,E,M,P* 

Hewlett-Packard Co. 
9600-H Southern Pine Blvd. 
CHARLOTTE, NC 28210 
Tel: (704) 527-8780 
C* 

Hewlett-Packard Co. 
5605 Roanne Way 
GREENSBORO, NC 27420 
Tel: (919) 852-1800 
A,C.CM,E,M,P* 

Ohio 

Hewlett-Packard Co. 
2717 S. Arlington Road 
AKRON, OH 44312 
Tel: (216) 644-2270 
C,E 

Hewlett-Packard Co. 
23200 Chagrin Blvd #100 
BEACHWOOD,OH44122 
Tel: (216) 292-4677 
C,P 

Hewlett-Packard Co. 
9920 Carver Road 
CINCINNATI, OH 45242 
Tel: (513) 891-9870 
CM 

Hewlett-Packard Co. 
16500 Sprague Road 
CLEVELAND, OH 44130 
Tel: (216) 243-7300 
A,C,CM,E,M 

Hewlett-Packard Co. 
9080 Springboro Pike 
MIAMISBURG, OH 45342 
Tel: (513) 433-2223 
A,C,CM,E*,M 

Hewlett-Packard Co. 

One Maritime Plaza, 5th Floor 

720 Water Street 

TOLEDO, OH 43604 

Tel: (419) 242-2200 

C 

Hewlett-Packard Co. 
675 Brooksedge Blvd. 
WE8TERVILLE, OH 43081 
Tel: (614) 891-3344 
CCM.E* 

Oklahoma 

Hewlett-Packard Co. 
3525 N.W. 56th St. 
Suite C-100 

OKLAHOMA CITY, OK 731 12 
Tel: (405) 946-9499 
C,E*,M 

Hewlett-Packard Co. 
3840 S. 103rd E. Ave., 100 
TUL8A, OK 74146 
Tel: (918) 665-3300 
A**,C,E,M*,P* 



Oregon 

Hewlett-Packard Co. 
9255 S. W. Pioneer Court 
WIL80NVILLE, OR 97070 
Tel: (503) 682-8000 
A,C,E*,M 

Pennsylvania 

Hewlett-Packard Co. 
50 Dorchester Rd. 
HARRI8BURG, PA 17112 

Tel: (717) 657-5900 
C 

Hewlett-Packard Co. 
1 1 1 Zeta Drive 
PinSBURGH, PA 15238 
Tel: (412) 782-0400 
A,C,E,M 

Hewlett-Packard Co. 
2750 Monroe Boulevard 
VALLEY FORGE, PA 19482 
Tel: (215) 666-9000 
A,C,CM,E,M 

South Carolina 

Hewlett-Packard Co. 
Brookside Park, Suite 122 
1 Harbison Way 
COLUMBIA, SC 29210 
Tel: (803) 732-0400 
CM 

Hewlett-Packard Co. 
555 N. Pleasantburg Dr. 
Suite 107 

GREENVILLE, SC 29607 
Tel: (803) 232-8002 
C 

Tennessee 

Hewlett-Packard Co. 
One Energy Centr. 200 
Pellissippi Pkwy. 
KNOXVILLE,TN 37932 
Tel: (615) 966-4747 
A,CM 

Hewlett-Packard Co. 
3070 Directors Row 
Directors Square 
MEMPHIS, TN 38131 
Tel: (901) 346-8370 
A,CM 

Hewlett-Packard Co. 

220 Great Circle Road, Suite 116 

NASHVILLE, TN 37228 

Tel: (615) 255-1271 

CM.P* 



Texas 

Hewlett-Packard Co. 
1826-P Kramer Lane 
AUSTIN, TX 78758 
Tel: (512) 835-6771 
CE,P* 

Hewlett-Packard Co. 
5700 Cromo Dr 
EL PASO, TX 79912 
Tel: (915) 833-4400 
CE*,M** 

Hewlett-Packard Co. 
3952 Sandshell Drive 
FORT WORTH, TX 76137 
Tel: (817) 232-9500 
C 

Hewlett-Packard Co. 
10535 Hanwin Drive 
HOUSTON, TX 77036 
Tel: (713) 776-6400 
A,CE,M,P* 

Hewlett-Packard Co. 

511 E. John W. Carpenter Fwy. 

Royal Tech. Center 100 

IRVING, TX 75062 

Tel: (214) 556-1950 

CE 

Hewlett-Packard Co. 
109 E. Toronto, Suite 100 
McALLEN,TX 78503 
Tel: (512) 630-3030 
C 

Hewlett-Packard Co. 
930 E. Campbell Rd. 
RICHARDSON, TX 75081 
Tel: (214) 231-6101 
A,CCM,E,M,P* 

Hewlett-Packard Co. 
1020 Central Parkway South 
SAN ANTONK),TX 78216 
Tel: (512) 494-9336 
A,CE,M,P* 



Utah 

Hewlett-Packard Co. 
3530 W. 2100 South 
SALT LAKE CITY, UT 841 19 
Tel: (801) 974-1700 
A,C,E,M 

Virginia 

Hewlett-Packard Co. 
4305 Cox Road 
GLEN ALLEN, VA 23060 
Tel: (804) 747-7750 
A,C,E,M,P* 

Hewlett-Packard Co. 

Tanglewood West BIdg. 

Suite 240 

3959 Electric Road 

ROANOKE, VA 24018 

Tel: (703) 774-3444 

CE,P 



Washington 

Hewlett-Packard Co. 
15815 S.E. 37th Street 
BELLEVUE,WA 98006 
Tel: (206) 643-4000 
A,CCM,E,M 

Hewlett-Packard Co. 
708 North Argonne Road 
SPOKANE, WA 99212-2793 
Tel: (509) 922-7000 
C 

West Virginia 

Hewlett-Packard Co. 
501 56th 
CHARLESTON, WV 25304 

Tel: (304) 925-0492 
A,CM 

Wisconsin 

Hewlett-Packard Co. 
275 N. Corporate Dr. 
BROOKFIELD,WI 53005 
Tel: (414) 784-8800 
A,CE*,M 

URUGUAY 

Pablo Ferrando S.A.C e I. 

Avenida Italia 2877 

Casilla de Correo 370 

MONTEVIDEO 

Tel: 80-2586 

Telex: 802586 

A,CM,E,M 

Olympia de Uruguay S.A. 
Maquines de Oficina 
Avda. del Libertador 1997 
Casilla de Correos 6644 
MONTEVIDEO 
Tel: 91-1809, 98-3807 
Telex: 6342 OROU UY 
P 

VENEZUELA 

Hewlett-Packard de Venezuela C.A. 

3A Transversal Los Ruices Norte 

Edificio Segre 2 & 3 

Apartado 50933 

CARACAS 1071 

Tel: 239-4133 

Telex: 251046 HEWPACK 

A,CCM,E,M,P 

Hewlett-Packard de Venezuela, C.A. 

Centre Civdad Comercial Tamanaco 

Nivel C-2 (Nueva Etapa) 

Local 53H05 

Chuao, CARACAS 

Tel: 928291 

P 

Albis Venezolana S.R.L. 
Av. Las Marias, Ota. Alix, 
El Pedregal 
Apartado 81025 
CARACAS 1080A 
Tel: 747984, 742146 
Telex: 24009 ALBIS VC 
A 

Tecnologica Medica del Carlbe, C.A. 

Multicentre Empresarial del Este 

Ave. Libertador 

Edit. Libertador 

Nucleo "C" - Oficina 51-52 

CARACAS 

Tel: 339867/333780 

M 



Hewlett-Packard de Venezuela C.A. 

Residencias Tia Betty Local 1 

Avenida 3 y con calfe 75 

MARACAIBO,EstadoZulia 

Apartado 2646 

Tel: (061) 75801-75805-75806- 

80304 

Telex: 62464 HRMAR 

CE* 

Hewlett-Packard de Venezuela C.A. 

Urb. Lomas de Este 

Torre Trebol — Piso 1 1 

VALENCIA, EstadoCarabobo 

Apartado 3347 

Tel: (041) 222992/223024 

CP 

YUGOSLAVIA 

Do Hermes 
General Zdanova 4 
YU-11000BEOGRAD 
Tel: 340 327, 342 641 
Telex: 11433 
A,CE,P 

Hermes 

Titova 50 

YU-61000 LJUBUANA 

Tel: 324 856, 324 858 

Telex: 31583 

CE,M,P 

Elektrotehna 
Titova 51 

YU-61000 UUBUANA 
CM 

ZAIRE 

Computer & Industrial Engineering 

25, Avenue de la Justice 

B.P. 12797 

KINSHASA, Gombe 

Tel: 32063 

Telex: 21552 

CP 

ZAMBIA 

R.J. Tilbury (Zambia) Ltd. 

P.O. Box 32792 

LUSAKA 

Tel: 215590 

Telex: 40128 

E 

ZIMBABWE 

Field Technical Sales (Private) Limited 

45, Kelvin Road North 

P.O. Box 3458 

HARARE 

Tel: 705 231 

Telex: 4-122 RH 

E,P 
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